Re: DVM - D Version Manager 0.3.0 (including support for Windows)
Am 01.08.2011 22:53, schrieb Andrej Mitrovic: I know this is maybe obvious for linux geeks, but your shell command won't work like this: wget -O dvm https://bitbucket.org/doob/dvm/downloads/dvm-0.3.0-linux-32 chmod +x dvm ./dvm install dvm Because you have to call this before executing dvm: chmod +x dvm This is included in the command above?
Re: D programming language specification ebook
Am 10.07.2011 12:19, schrieb Walter Bright: On 7/10/2011 1:02 AM, Russel Winder wrote: Development, and particularly compilation, is a different matter. The introduction of the ability to import from a non-local Git, Mercurial or Bazaar repository embeds the assumption of permanent connectivity of the developer's machine to the Internet. That'd cut my productivity in half. My internet connection frequently goes down for a minute to 5 minutes. Cloud applications are just not feasible. There have been suggestions to add something like this to dmd. imports from URLs or something like that - because its faster than having a build tool do this (try to build - realize that dependency is missing from DMDs error message - download dependency from central repository - try to build again ...) Cheers, - Daniel
Re: DVM Windows Beta #2 - Up To Date With v0.2.0
Am 04.07.2011 03:01, schrieb bearophile: Andrej Mitrovic Wrote: Is there a limit to how far DMD releases are supported? You are able to find very old versions of DMD too, all the way to the latest one. This is the support. I think he was talking about how far DVM supports old DMD releases, not the support/availability from the D project (I hope I didn't misunderstand you ;-)). Cheers, - Daniel
Re: TDPL is an Amazon Kindle bestseller
Am 21.06.2011 01:37, schrieb Walter Bright: On 6/20/2011 12:13 PM, Nick Sabalausky wrote: I've been guessing that will only happen when DRM starts going away. Sadly, any DRM books you buy on the Nook aren't usable on the Kindle and vice versa. (I sent this reply yesterday, but it seems like the server lost it) DRM is generally a bad idea - especially for stuff you buy and not just rent. Once the DRM servers are down (because the company is bankrupt or stops the service) your books/music/movies/... are gone. Because of that I'd never buy E-Books or music with DRM - if I buy a book I want to be able to read it again in 20 years - same with music. Plus I want to be able to play music on any device (like my car radio) and not just on my PC or iPod. So I agree with Nick: Until E-Books are DRM free (and have a standard format that works on any E-Book reader, but I think this is already available) they (hopefully!) won't supersede paperbacks. Another thing is that I actually like having real books in my shelf, just like CDs and computer games (it already pisses me off that the they are usually distributed in DVD cases now and not anymore in these big cardboard boxes). Cheers, - Daniel
Re: Programming Windows D Examples are now Online!
Am 21.06.2011 06:14, schrieb Andrej Mitrovic: This is a translation project of Charles Petzold's Programming Windows (5th edition) book code samples. Currently over 120 code samples have been translated into D, with only a few modules remaining. Everything else you need to know is in the Readme file: https://github.com/AndrejMitrovic/DWindowsProgramming The examples were tested on fresh installs of XP and Win7 with the only dependency being DMD v2.053 and an NT operating system. I hope everyone will be able to build these examples without too much trouble. *crosses fingers* The README mentions 2.043 instead of 2.053. Cheers, - Daniel
Re: DMD/Objective-C Alpha 1
Am 02.06.2011 17:12, schrieb Robert Clipsham: On 02/06/2011 16:09, Jacob Carlborg wrote: On 2011-06-02 15:21, Robert Clipsham wrote: The lack of line numbers in debug info on OS X is something that's really annoying me, I may look into this in the future should I get chance - if someone doesn't beat me to it of course. Wouldn't be the first time I'd spent a week playing with dmd's debug info to get it working... http://d.puremagic.com/issues/show_bug.cgi?id=4154 Oh cool - does this patch work then? Have you made a pull request for it? According to the bugreport it doesn't work properly: I've attached a patch which fixes this. But with this patch (I think) one or several offsets somehow become incorrect. This is the output of dwarfdump --verify: The offset into the .debug_abbrev section (0x) is not valid. Maybe it's because the section names are now one character longer or there is something other that isn't working.
Re: Learning With D
Am 23.05.2011 20:51, schrieb bearophile: Russel Winder: Uuuurrr... this is just wrong on so many levels. To avoid writing an 10,000 word essay, I'll just stick to: Python and Groovy have proven to be excellent languages for teaching first year undergraduates and adults. I have chosen Python to teach programming at new university students that know nearly nothing about programming. I think Python is among the best languages currently available to teach programming (Python partially comes from ABC, a language mostly designed for teaching), but it's far from perfect still for this purpose: - I appreciate Python significant indentation a lot, but I've seen it cause problems to some students. What kind of problems? (related to tabs vs spaces?) - Dynamic typing is handy, but it makes it a bit harder to learn the discipline of types. Yeah, I personally don't like dynamic typing at all. - Confusing variable creation and variable update is not good to teach programming to newbies and causes problems. - Many programming newbies are blind to the diffences in case, for them FOR and for are the same word, so a case agnostic language as Pascal is may be better for such people. I strongly disagree. The first language they learn should *not* be agnostic to case, so they learn that case matters (because it does in most languages). - The lack of built-in rationals doesn't help. - Lazy computations, introduced since some years in Python are a useful and powerful tool, but for a newbie it's one more complexity to learn and manage. - All variables managed by reference (by name) is good for uniformity (and efficiency!), but it also introduces some complexities and bugs that newbies don't like a lot. - Python doesn't support recursion in a good enough way. - Python error messages and debugging is far from the best. If you take a look at the IDE of Racket Scheme you see something far more newbie-friendly. Note: your posts come out empty through the web interface: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announcearticle_id=20572 Bye, bearophile
Re: Learning With D
Am 23.05.2011 21:53, schrieb bearophile:
Daniel Gibson:
- I appreciate Python significant indentation a lot, but I've seen it cause
problems to some students.
What kind of problems? (related to tabs vs spaces?)
Tabs Vs spaces is not a big problem once you have told students to set up all
their editors to never emit a tab :-) So this is not the real problem.
Different people have very different brains, some people find easy certain
things and other people find easy other things. A good teacher must adapt
himself/herself/hirself to the brain of the different students. Significant
indentation has some good advantages, it reduces noise, it makes the
semantics of the code the same of what you see, etc. But some programming
newbies just aren't precise enough, they lose control and count of
indentations, etc. For them spaces are nothing, they don't even see them, so
for them braces are probably better, despite the increase in noise.
OTOH python teaches to indent your code properly which enhances
readability, so maybe it's a good thing to learn right from the beginning.
I've had students producing working code (Java and SQL) that was totally
unreadable because it wasn't indented properly.
- Dynamic typing is handy, but it makes it a bit harder to learn the
discipline of types.
Yeah, I personally don't like dynamic typing at all.
We are discussing about a language used as first programming language. What's
good for an programmer that is programming since two years is sometimes not
the best for a newbie and vice versa too. Finding a good balance for newbies
between Pascal/Java-style boring and stupid static typing, full type
inference as in ML, and full dynamic typing as in Python, is not easy.
I strongly disagree. The first language they learn should *not* be
agnostic to case, so they learn that case matters (because it does in
most languages).
Most languages are strict in their case. So sooner or later a programmer must
learn to tell apart cases of keywords and variables.
Exactly. So why teach it in a differently first and then tell well, now
you're using a proper language and now you have to start caring about
case? This just asks for subtle bugs because of spelling mistakes..
class Bar {
int p;
void setFoo(int P) { this.p = p; }
}
and stuff like that.
But the case of keywords is _not_ essential to learn the basics of
programming. There are so many things to learn in the beginning. And Pascal
has being used to successfully teach generations of programmers. So while I
respect your point of view, I think this is something different teachers are
allowed to disagree on :-)
It may not be essential. Neither is correct spelling; so the language
could be fuzzy about detecting keywords so to { ... } wihle(...);
could be accepted as well :-P
Also: What are the basics or programming? Isn't expressing what you
want in a precise way part of it? And caring about case is part of being
precise IMHO.
Bye,
bearophile
Cheers,
- Daniel
Re: Learning With D
Am 23.05.2011 22:51, schrieb Adam D. Ruppe: bearophile wrote: For them spaces are nothing, they don't even see them, so for them braces are probably better This is the biggest thing that trips me up with Python. Something indenting inward is pretty easy to see, but going outward is often skipped by my eyes. def foo(): # i see this change # but here I don't register the change and think I'm still in foo() I wonder if part of the confusion is from indented paragraphs in normal English. The most difficult thing to see is two or more indents changing at once though... counting groups of spaces is weird. Scintilla based editors (like SciTE and Geany) have indentation guides, see http://www.joeflash.ca/blog/2009/03/indentation-guides-in-flex-builder.html for a screenshot (that's not my page, I found this via google). That should help. Cheers, - Daniel
Re: Learning With D
Am 24.05.2011 01:59, schrieb bearophile:
Daniel Gibson:
OTOH python teaches to indent your code properly which enhances
readability, so maybe it's a good thing to learn right from the beginning.
I've had students producing working code (Java and SQL) that was totally
unreadable because it wasn't indented properly.
Some students are precise, they puts all the full stops and commas in their
comments, and format code well. Other students seem unable to understand the
need for a proper code formatting. But both kinds of students must learn some
programming and do some practice at it. The teacher has to ask for a good
code formatting, but I have seen it's better to avoid an escalation of the
frustration of the less precise programmers, otherwise they may lose interest
in programming and sometimes even switch courses :-) They already hate the
interpreter/compiler for all those stupid error messages it gives them...
How do you do less precise programming? Just change your code until
the compiler stops emitting error messages and until the output of your
program looks about right for some sample input?
IMHO the sooner they learn to be precise the better - randomly changing
code until it compiles is no programming but a sign that the
programmer hasn't got a clue what he's doing.
Furthermore I'm not sure whether setting correct parentheses is easier
than correct indenting for these kind of students (or will they just add
parentheses until the compiler shuts up)?
(WTF am I really defending a scripting language?)
Exactly. So why teach it in a differently first and then tell well, now
you're using a proper language and now you have to start caring about
case?
Delphi is a proper language (better than C, by the way).
Maybe, doesn't change the fact that most other languages are case
sensitive. And as a Linux user (with case sensitive file systems) I
think people should get used to case sensitivity.
The first language you use doesn't need to be the same language you use 8
months later. Ignoring cases first, and later asking for a more strict
programming style is not bad, it's exactly what lot of students used to do
learning Pascal the first year and C the second :-)
And learning Pascal in the first and C in the second year is good?
This just asks for subtle bugs because of spelling mistakes..
class Bar {
int p;
void setFoo(int P) { this.p = p; }
}
and stuff like that.
Have you programmed in Delphi/ObjectPascal for some weeks or more?
Case-related bugs are not common. I am not talking about removing case
sensitivity from C/Java, I am talking about a language wholly designed taking
into account it is case insensitive.
I've learned Delphi in school (didn't learn that much in retrospect, I
wasn't taught about records, classes, pointers, ... but we always
clicked a nice GUI..) but didn't even know it was case insensitive.
It may not be essential. Neither is correct spelling; so the language
could be fuzzy about detecting keywords so to { ... } wihle(...);
could be accepted as well :-P
People that don't know how to switch on a computer know that in their natural
language the word the means the same thing if you write it lowercase in the
middle of the phrase, or if you write it capitalized as The at the
beginning of a phrase. But even programming newbies (unless they have
dyslexia, and some new programmers _do_ have strong dyslexia, and the teacher
must find a ways to teach them too something) are able to see that hte is a
word different from the. So this argument of yours is not good enough.
Even programming newbies can easily learn that The != the.
Bye,
bearophile
Re: Learning With D
Am 23.05.2011 01:29, schrieb Ali Çehreli: On 05/21/2011 11:12 PM, Jesse Phillips wrote: I started writing what I hoped would turn into a fairly complete book. Thank you for doing this! :) This book is intended to teach programming from the ground up. I have some experience in doing the same. Just like teaching in the classroom, no matter what style or detail has been chosen, readers will find the material anywhere from very easy to exteremly difficult. :) One (draft of an) article on teaching programming that had struck a chord with me has been http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf They divide the students in three groups. They argue that the ones that are successful in programming are the ones who can form consistent models for unknown phenomena. (Not their exact words, but what I got out of the paper.) We all know D would make a very good first language Agreed. Although there are so many high level concepts in the language, starting to write simple programs is very easy. For example, one can go a long way without even knowing that pointers exist. Additionally, having to introduce the concept of a reference type earlier makes it easy to explain pointers later on. I think explaining pointers first (including you have to dereference it to get to the thing it's pointing at, to show the difference between pointer and pointee) may be a better idea. After that you can say and objects of classes are reference types, they behave like pointers but don't need all the ugly syntax And I think http://www.youtube.com/watch?v=i49_SNt4yfk is a great video explaining pointers ;) And I really want the user to go from first time Python programmer to basic C programmer. I think, that is a more accurate description than the one in Chapter 1: (expected starting experience of none). I can imagine that some people will find your book a little too fast. (And others will find it too slow! :)) One approach that I think many will like is the Common Errors sections which is meant to help people identify what the compiler is saying when things go wrong. That is going to be very helpful. Thank you, Ali
Re: DVM - D Version Manager 0.2.0
Am 18.05.2011 14:21, schrieb Steven Schveighoffer: On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky a@a.a wrote: But the bottom line seems to be: Linux is in a bigger DLL hell than windows has ever been, and I don't think *anyone* actually knows how to do it. This is one of the side effects of having open source software. Since everything on linux is expected to be open source, it's expected that you simply recompile everything for your system. In this respect, Windows has Linux beat hands down. A hardware company that builds a driver needs only to support one compiled driver that just keeps working no matter how many times XP is updated. Drivers are completely different from normal applications on Linux. Because the Kernel changes all the time you have to change drivers quite often. The userspace should be more stable - AFAIK the kernel ABI is backwards compatible since kernel 0.99 or something, i.e. programs from back than should still work. In practice there is some kind of DLL hell because old software may rely on old libs that are not available on newer distributions (or only in not backward-compatible versions). For Open Source software that is not that much of a problem, often it's sufficient to recompile.. Closed source software on Linux often supplies almost all needed libraries to avoid problems with preinstalled libs - or is even statically linked. I think this is the same on Windows.. Also, as Nick mentioned, it helps to compile software on a older distribution, because many libs are at least backwards compatible (to a certain degree), but not the other way round, so it still works on newer/recent distributions - while compiling on your newest bleeding edge beta Ubuntu (or Debian unstable or whatever) will quite likely produce binaries that won't work on older distributions. I maintain Debian/Ubuntu packages for a Quake2 port (Yamagi Quake2) and building them on a old Debian etch chroot jail produces binaries that work on about any Debian/Ubuntu from the last years (at least there never have been complaints that it doesn't work). I think reading some of the issues with MacOSX breaking dmd builds by going through a *point* revision, it sounds like MacOSX is just as bad. Strange, considering that MacOSX isn't open and there are not a several different distributions of it. At my previous company, we integrated software from pure software companies into their required OSes and hardware, and did all the OS/hardware dirty work for them (i.e. we turned pure software into an appliance). One of the *worst* problems was when the customer wanted some version of Linux, and let's say they had a specific kernel build. Because of the expectation from the Linux kernel that you just recompile all your drivers, any RAID card (a very common requirement) which had proprietary driver code would require us to contact the hardware vendor, and have them rebuild the RAID driver on their specific kernel (for a not-so-nominal fee of course, with very little support). That's why you should use hardware that doesn't rely on proprietary drivers on Linux. If the driver is integrated in the Kernel you don't have to worry if it still works after minor or major upgrades. On Windows you may have hardware that is supported on Windows XP, but not on Win7 etc. I think using hardware with free/open drivers is realistic for about any hardware besides video cards - although the open drivers for AMD/Ati are getting better. And the proprietary drivers for them are compatible to any recent kernels (apart from maybe the most recent one, but you won't find that in distributions anyway). You just have to be a bit careful and choose your hardware accordingly. I fantasized about building my own linux kernel that had zero configuration options, and would never break driver compatibility between point revisions. Such a kernel would allow hardware companies to release one driver and have it work for any system that used their hardware and that kernel. Like Redhats 2.6.18 fork they maintained forever? I can't imagine hardware companies love supporting umpteen driver versions multiplied by umpteen linux vendors (generally they only pick one vendor and support that). Yeah, they should just donate the driver to the kernel (or at least release HW specs so somebody else can write an open driver) and let the kernel developers maintain it. Of course, that dream would be impossible to realize without tremendous effort, which I don't have. Ah well. -Steve Cheers, - Daniel
Re: DVM - D Version Manager 0.2.0
Am 18.05.2011 17:20, schrieb Steven Schveighoffer: On Wed, 18 May 2011 10:47:02 -0400, Daniel Gibson metalcae...@gmail.com wrote: Am 18.05.2011 14:21, schrieb Steven Schveighoffer: At my previous company, we integrated software from pure software companies into their required OSes and hardware, and did all the OS/hardware dirty work for them (i.e. we turned pure software into an appliance). One of the *worst* problems was when the customer wanted some version of Linux, and let's say they had a specific kernel build. Because of the expectation from the Linux kernel that you just recompile all your drivers, any RAID card (a very common requirement) which had proprietary driver code would require us to contact the hardware vendor, and have them rebuild the RAID driver on their specific kernel (for a not-so-nominal fee of course, with very little support). That's why you should use hardware that doesn't rely on proprietary drivers on Linux. If the driver is integrated in the Kernel you don't have to worry if it still works after minor or major upgrades. On Windows you may have hardware that is supported on Windows XP, but not on Win7 etc. I don't want to get into a philosophical debate here, but this is truly unrealistic. I think it's one of the main reasons many hardware companies don't support Linux. Opening the source does not mean you will not support it, and then you have to deal with 8 million configuration options for the kernel to test against your driver. As a hardware company whose main purpose is not writing drivers, that sounds like a QA nightmare. I don't know much about coding for the kernel, but I guess that most of the configuration options shouldn't affect your driver. Of course there may still be a lot of options left that could affect your driver. Yes, XP drivers don't work on Windows 7, but they work on XP, and there is only *one* XP. Furthermore, Microsoft *purposely* does not invalidate existing drivers. Compare that to Linux, where not only do the interfaces in the kernel change from revision to revision, but someone is *rebuilding* the entire kernel and all the drivers on every revision. I'm surprised it works as well as it does. Case in point, while I was using Linux as my main OS, an upgrade of the Fedora kernel simply broke my sound card driver. There was no changes to the driver, and I really never figured out what happened, but an upgrade to the next major release fixed the problem. There is absolutely no reason for existing drivers to break on a minor upgrade. Are you sure that it wasn't some userspace fuckup? Also: bugs in the kernel and drivers are always possible, especially when using a bleeding edge distribution like Fedora. I think using hardware with free/open drivers is realistic for about any hardware besides video cards - although the open drivers for AMD/Ati are getting better. And the proprietary drivers for them are compatible to any recent kernels (apart from maybe the most recent one, but you won't find that in distributions anyway). You just have to be a bit careful and choose your hardware accordingly. Printer support is woefully missing. My 2-year old printer still isn't supported on Linux. As I said, you have to choose your hardware accordingly. There are a lot of printers that have really good Linux support - more expensive ones via postscript and/or PCL, cheap ones (especially inkjets) often need some proprietary libs, that are however independent of the kernel and tend to work, even when they haven't been updated for some years (cheap HP printers are often supported via HPs open source hplip driver). http://www.openprinting.org/printers is pretty helpful and the proprietary drivers are available from the printer vendors (for example Brother supports many of their printers), so it's a good idea to look on that page and on the vendors page for linux support before buying a printer ;-) I fantasized about building my own linux kernel that had zero configuration options, and would never break driver compatibility between point revisions. Such a kernel would allow hardware companies to release one driver and have it work for any system that used their hardware and that kernel. Like Redhats 2.6.18 fork they maintained forever? Not really. I mean freeze the configuration options for the kernel -- they can never change except for a major release. Then, don't recompile the drivers for every kernel update. Maintain *binary* compatibility for drivers, so one never has to recompile them unless the driver itself has a bug. I can't imagine hardware companies love supporting umpteen driver versions multiplied by umpteen linux vendors (generally they only pick one vendor and support that). Yeah, they should just donate the driver to the kernel (or at least release HW specs so somebody else can write an open driver) and let the kernel developers maintain it. This isn't
Re: DVM - D Version Manager 0.2.0
Am 18.05.2011 21:22, schrieb Steven Schveighoffer: On Wed, 18 May 2011 14:51:18 -0400, Robert Clipsham rob...@octarineparrot.com wrote: On 18/05/2011 16:20, Steven Schveighoffer wrote: Printer support is woefully missing. My 2-year old printer still isn't supported on Linux. Now this is beyond me. Everyone I've talked to says printer support in Linux sucks, but I've been through several printers, and Linux has been the only operating system I've used that's had no problems with it. Regardless of the distro, it picks up a local or network printer and allows me to print without any configuration whatsoever - apparently it doesn't 'just work' for anyone else though. In OS X and Windows I have to manually find network printers and find drivers online, only the latter for local printers. Even then they don't always work. At work, since I've been here (almost 2 years), my laptop always cuts off about 1/8 of an inch from the left of the page. Until the latest upgrade to ubuntu 11, I would have to adjust the image quality to 1200 dpi every time I printed (even from the same application) or else any graphics on a page would be super-grainy like I printed it in 1995. I'm sure it works great in some cases. Just not in general. And mostly not for me :( -Steve http://localhost:631 Printers - click on that printer - Administration - Set Default Options - General - Print Quality
Re: Goldie Parsing System v0.4 Released - Now for D2
Am 15.04.2011 09:50, schrieb Nick Sabalausky: Since you're talking about C, you'll probably want to run your original C code through the preprocess-only option of a real C compiler. (I *think* DMC will do that.) Then parse the resulting preprocessed C files with Goldie. (Although if your goal is an HTOD-like tool, maybe you would need to deal with the original un-preprocessed source directly. Why? Just call the preprocessor from your tool or from a wrapping script and go on with the preprocessed C code. Should be much easier and more compatible because C compilers ought to know how to preprocess correctly. For GCC the option you're looking for is -E, btw. If Golde's grammar langauge doesn't seem quite up to the task, it probably wouldn't bee too hard to just manually make a basic C preprocessor.) Cheers, - Daniel
Re: Goldie Parsing System v0.4 Released - Now for D2
Am 15.04.2011 10:13, schrieb Nick Sabalausky: Daniel Gibson metalcae...@gmail.com wrote in message news:io8u12$132q$1...@digitalmars.com... Am 15.04.2011 09:50, schrieb Nick Sabalausky: Since you're talking about C, you'll probably want to run your original C code through the preprocess-only option of a real C compiler. (I *think* DMC will do that.) Then parse the resulting preprocessed C files with Goldie. (Although if your goal is an HTOD-like tool, maybe you would need to deal with the original un-preprocessed source directly. Why? Just call the preprocessor from your tool or from a wrapping script and go on with the preprocessed C code. Should be much easier and more compatible because C compilers ought to know how to preprocess correctly. For GCC the option you're looking for is -E, btw. If by your tool mean a program that uses Goldie to process C code, then yea, that's what I meant. I meant Andrej's hypothetical tool using Goldie to process C code :-)
Re: [Article Context, First Draft] Concurrency, Parallelism and D
Am 10.04.2011 00:27, schrieb Torarin: 2011/4/8 dsimcha dsim...@yahoo.com: Here's a first draft of an article on D's approaches to concurrency and parallelism for D's article contest. It's not an official submission yet, but feedback would be appreciated. http://davesdprogramming.wordpress.com/2011/04/07/7/ A very good article! And I like that you linked to other articles that go into more detail on relevant subjects. I wouldn't mind a couple more examples. Torarin After all the language bikeshedding I'll add something on-topic to this thread ;) I agree with Torarin: It's a very good article, I like how further explanations are linked and I also wouldn't mind some more examples. Some additional notes: * A link to the std.parallelism docs would make sense * This means that no data that is not either immutable or shared may be transitively reachable via pointers or references passed into a spawned function or passed as a message. is a strange sentence with those two negations in it. * Maybe you could compare std.parallelism to OpenMP in terms of syntax and functionality? That would probably help all the people that are familiar with it. Cheers, - Daniel
Re: [Article Context, First Draft] Concurrency, Parallelism and D
Am 10.04.2011 04:27, schrieb dsimcha: On 4/9/2011 10:22 PM, Andrei Alexandrescu wrote: On 04/09/2011 08:31 PM, dsimcha wrote: On 4/9/2011 7:56 PM, Andrei Alexandrescu wrote: I think the article's title is missing a comma btw. Andrei Where? Where could it ever be? After parallelism. Andrei Actually, I specifically remember learning about this grammar rule in middle school. When listing stuff, the comma before the and is optional. Putting it and not putting it are both correct. Having both and and the comma seems redundant to me. But I'm German and we don't have a comma before and (und) in lists* so maybe I'm just not used to it. Cheers, - Daniel * an Exception is when a subordinate clause ends before the and, like in I know programming languages like C, D, which kicks ass, and Java
Re: [Article Context, First Draft] Concurrency, Parallelism and D
Am 10.04.2011 06:04, schrieb Jonathan M Davis: Am 10.04.2011 04:27, schrieb dsimcha: On 4/9/2011 10:22 PM, Andrei Alexandrescu wrote: On 04/09/2011 08:31 PM, dsimcha wrote: On 4/9/2011 7:56 PM, Andrei Alexandrescu wrote: I think the article's title is missing a comma btw. Andrei Where? Where could it ever be? After parallelism. Andrei Actually, I specifically remember learning about this grammar rule in middle school. When listing stuff, the comma before the and is optional. Putting it and not putting it are both correct. Having both and and the comma seems redundant to me. But I'm German and we don't have a comma before and (und) in lists* so maybe I'm just not used to it. Cheers, - Daniel * an Exception is when a subordinate clause ends before the and, like in I know programming languages like C, D, which kicks ass, and Java I'm sure that the wikipedia article goes into a fair bit of detail on it, but there are cases where the lack of the comma leads to ambiguity. I believe that the current recommendation is to always put the comma in, but it's bound to depend on who you talk to - even among English teachers. - Jonathan M Davis You can always have ambiguities, e.g. I know programming languages like C, D, my favorite, Java and Haskell - does my favorite belong to the list or does it describe D? And shouldn't there be two commas after favorite (for me this kind of feels like a missing closing bracket)? Or, a slightly altered version of a wikipedia example: Among those interviewed were his three ex-wives, Kris Kristofferson, Horst Hacker and Robert Duvall. - are Kris, Horst and Robert his ex-wives (same problem like in the original wikipedia example)? Alternative version: Among those interviewed were his three ex-wives, Kris Kristofferson, Horst Hacker, and Robert Duvall. - not better at all: It's not clear whether Kris Kristofferson, Horst Hacker, and Robert Duvall is a list of ex-wives (it's a list, so we put a comma before the and etc) or if his three ex-wives, Kris Kristofferson, Horst Hacker, and Robert Duvall. is a list of six people. So I think a comma before and doesn't help very much in solving ambiguities. Cheers, - Daniel
Re: [OT] Re: Short forum post on REST API
Am 03.04.2011 08:59, schrieb Nick Sabalausky: Daniel Gibson metalcae...@gmail.com wrote in message news:in889j$knb$1...@digitalmars.com... Am 03.04.2011 00:22, schrieb Adam D. Ruppe: Nick Sabalausky: Heh, yup. Because after all, VRML just went over sooo well. Yeah... what's old is new again fits so well to web 2.0. WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser! If it helps killing Flash I'm fine with WebGL, My immeditate reaction is to agree with you on that, because direct experience as both a flash-user and as a flash-developer has given me a strong personal hatred towards Flash. But, if WebGL is driven by in-browser JS (as I *think* it is, not that I've studied it closely), then I dunno, suddenly Flash doesn't sound quite so bad anymore. Heck, at the very least, Flash is already in byte-code when it's distributed, and the JS-as-the-web's-asm idea just gives me a rash. Plus it's cleaner/easier to block flash than to block specific JS features. Etc. But Flash is a notorious security hole, sometimes crashes the browser, ... [If it helps killing Flash I'm fine with] HTML5-videotag I dunno. The thing that still bugs me about that is we *already* had the object tag, The problem was that there were different codecs for videos (windows media, real media, ...) and often websites prompted you to install their codec.. which sometimes distributed malware etc. It's better to have a video tag with a standard codec that is supplied by the browser. but then ever since YouTube came along everyone just stopped using it, Google outright left it out of Chrome, etc. It was just plain killed off in favor of flash. And now, ages later, they reinvent the object tag and try to convince me it'll finally pull web-A/V out of the flash shackes that *they* had placed web-A/V into in the first place? Even if I did feel that I could trust that claim (a shaky prospect), the fact remains that we *already* had a solution. (I hope google's WebM will win) etc. Oh god yes. I suppose everyone knows I'm, well, not exactly a big Google fan, but the legal ball-and-chain that's welded to H.2[0-9][0-9] (whatever the hell it's called) just leaves it a complete non-option, IMO. I'd sooner use flv and an embedded player - and I've always hated the whole concept of flash video players. Flash also supports H.264 and other patented MPEG crap.
Re: [OT] Re: Short forum post on REST API
Am 03.04.2011 00:22, schrieb Adam D. Ruppe: Nick Sabalausky: Heh, yup. Because after all, VRML just went over sooo well. Yeah... what's old is new again fits so well to web 2.0. WebGL gets more minus points too since its on shaky technical grounds too. It isn't very 'webby' if you will and may have security implications... but wheee you can make shitty ports of old games to the browser! If it helps killing Flash I'm fine with WebGL, HTML5-videotag (I hope google's WebM will win) etc. However that shouldn't be used in serious (non demo/showcase) websites until proper support is ready in all major browsers. As a web developer you should be glad that IE5/6's days are over and browsers are a more standard-conformant - or did you like writing a different version of your websites for each browser? A friend of mine who does web programming complained about having to work around IE6's anomalies a lot until he could finally stop supporting it, so I'm kind of surprised that you and Nick seem to like these old versions of the IE. Cheers, - Daniel
Re: TDPL Amazon rank at 4-months high
Am 02.03.2011 01:26, schrieb Jordi Sayol: Al 01/03/11 21:57, En/na Walter Bright ha escrit: Andrei Alexandrescu wrote: Yah, there are many variables. Add to those many handling details that influence the process. TDPL has certainly sold more than 1830 copies by now (= the collector's edition count) but booksellers have no obligation to send older prints first, so it all depends on which batch they have handy when shipping. Also I'm sure some smaller booksellers have gotten a batch from the collector's edition that hasn't been sold yet. It could be like milk. You buy a new carton of milk, and shove it in the refrigerator. When you need some, you grab the carton in front, which is the new one. So the old milk remains in stock for months, years, ... milk + years = poison :-) To solve this, somebody invented FIFO (first in, first out), and FILO (first in, last out), to solve storage problems. You'd need a fridge with two doors: one in the front, one in the back. Insert new food in the front, get food to eat from the back (or the other way round). But reinsert opened food in the back (or, in the alternative case, in the front). ;-)
Re: dmd 1.067 and 2.052 release
Am 21.02.2011 01:51, schrieb Graham St Jack: Fantastic news! Well done once again to the whole team. Now that the 64-bit bugbear is in the bag (along with a big pile of bugs), what is next? Is there a list somewhere detailing the planned language/toolchain changes that will make it into D2? Are we converging on a stable release of the language anytime soon? In particular, are there any plans to re-examine the tail-const issue in light of the compiler patch proposed by Michel Fortin in his post: const(Object)ref is here! back in December? Some other issues I assume are still in flux (and can remember) are: * Tweaks to usability of const/immutable/shared. * Tweaks to usability of nothrow, pure, etc. * Rollout of const, nothrow, pure, etc thoughout phobos. * Fate of the delete keyword. * Fate of the scope keyword used in object declaration and function parameters. * Meaning of in keyword for function parameters. Is it just const, and if so, why not just use const? I don't have (much) of a personal agenda here - I just want the rough edges smoothed off and a stable language. If I recall correctly, the next thing to be implemented was support for shared libraries (dmd being able to create create position-independent code (PIC)). Cheers, - Daniel
Re: Alternative linker win32/64
Am 18.02.2011 16:41, schrieb Andrei Alexandrescu: On 2/18/11 9:42 AM, dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article On 2/18/11 4:00 AM, Dmitry Olshansky wrote: The fresh beta of universal linker UniLink has arrived, with exciting new features. Wow. If this works out, it is the closest thing in real life to Deux ex machina. We were pretty much out of options. Andrei Let's say for the sake of discussion that UniLink does work. How close does that put us to having 64 support on Windows, too, if OptLink doesn't need to be translated/rewritten/whatever? AFAIK the linker is the largest roadblock, but Walter should really answer this question. Andrei I've got this message (and the other one from you in this thread) twice, one sent to the poster you were replying to and one without an explicit to, but both in this news group. Was that intended? Cheers, - Daniel
Re: New web newsreader - requesting participation
Am 03.02.2011 22:00, schrieb Lars T. Kyllingstad: On Thu, 03 Feb 2011 17:16:58 +, Adam Ruppe wrote: Eric Poggel wrote: I hate to mention this in light of Adam's work, but Reddit is open source--why not run our own deployment of it for D? I *really* dislike tree style interfaces. I find them incredibly hard to navigate. Of course, I'm fairly unlikely to use the web interface much anyway (whether mine or someone else - I prefer my mail client most the time), but still, it would be nice if it didn't suck. Anyway, I did a little more work on my thing this morning: http://arsdnet.net/d-web-site/nntp/thread-index?newsgroup=digitalmars.D There's now [Tree] and [Linear] links on the right to view the whole thread at once. Any ideas on how to improve that? I copied a few basic elements of reddit style sites, but I'm thinking that view works best for very short messages. I agree. Subject, author and date should be shown in a tree view, but you should never display more than one message body at a time. The average message on this forum is far too long for that. -Lars I find it annoying to open each message in a thread manually. I prefer a fully expanded thread with all bodies (or maybe partially expended by subthreads or something when it's too big). This makes reading longer threads much easier. I haven't found a non-web-based news/mail client that does this yet, but going to the next message with 'n' in Thunderbird certainly is less painful than clicking the next message I want to read on a website. Cheers, - Daniel
Re: New web newsreader - requesting participation
Am 31.01.2011 13:19, schrieb Nick Sabalausky: foobarf...@bar.com wrote in message news:ii62n0$1r3i$1...@digitalmars.com... 1. common human markup such as: _foo_ (underline), *foo* (bold) etc, I've never been much of a fan of that. Actually that's one of the things I didn't like about Thunderbird when I tried it: it kept replacing *'s and _'s with formatting even what I was in the supposed plaintext mode. Of course, if the *'s and _'s stay intact when the text is bolded/etc, then I can't say I'd care quite so much. This is exactly what my Thunderbird (okay, it's Icedove really) does. *,_,/ stays intact, but the text is bolded/underlined/italicized.
Re: DVM - D Version Manager
Am 27.01.2011 13:05, schrieb Jacob Carlborg: On 2011-01-26 23:46, Michel Fortin wrote: On 2011-01-26 15:24:56 -0500, Jacob Carlborg d...@me.com said: /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. But should it output this? $ /bin/sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. $ This is on Mac OS X 10.6.6. I have no idea. Perhaps it will run bash in a mode which is compatible with sh. Or just in normal mode, like linux distributions have been done for ages (and some still do). bash *is* compatible with sh (= everything that runs in sh runs in bash), but sh is not compatible with bash (= bash has features that other sh-compliant shells don't have and that are not required by the corresponding POSIX standard).
Re: Texas LinuxFest 2011 call for papers now open
Am 20.01.2011 19:58, schrieb Lutger Blijdestijn: Andrei Alexandrescu wrote: http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei This is a matter of perspective, I think these are the possibly interesting angles and issues for D: - availability and development of Open Source compilers (OSI compatible license) (x) we have gdc and ldc (check how well current versions with D2 work before talking about them, though ;)) - cross-platform design, this extends beyond linux but is often a concern and goal in the Open Source world (x) Windows, Linux, OSX, FreeBSD are supported, with gdc/ldc probably more - development process of the language (and std lib) itself: here the community participation is important. For D it's an interesting (and ongoing) story to tell. (x) agree. Also: The std lib is under a very free license (unlike for example suns/oracles classpath.. OpenJDK seems to be GPLed, but that still sucks for a std lib) - usefulness and place in the open source ecosystem: I believe D has a potential here as a serious alternative for both mono and java. Mono, the open source implementation of .net, has loads of potential patent issues and for this reason is not supported by some distro's. Java also has it's issues. Positioning D as a solution to those problems (rather than an alternative for C++ or dynamic languages) will please the crowd, for sure :) You can never be sure with patents, as someone else in another thread already pointed out: it's virtually impossible to write a piece of software that doesn't infringe patents. Of course, the situation is worse with Java (as seen in Oracle suing Google for using a Java-derivate in Android) and Mono (you never know if Microsoft will tolerate this forever. Even if they promised not to sue for current .net related patents, you never know about patents applying to features in future versions of .net). With D at least people still would have to find patents that are infringed - and even then the case isn't as clear as with Java/mono, where it's obvious that the Java/.net related patents are infringed. So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Interoperability with C is also important here. Yeah, it's a killer-feature. Being able to just call C functions and link objects produced by gcc objects (foo.o) is *really* helpful, especially in the Linux world. I think D (with gdc/ldc) qualifies as an Open Source Programming Language, but you should probably ask the texaslinuxfest guys for their personal definition. Cheers, - Daniel
Re: Texas LinuxFest 2011 call for papers now open
Am 20.01.2011 21:15, schrieb Lutger Blijdestijn: Daniel Gibson wrote: ... So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Technically that is right, but I find it a bit of an understatement because every non trival software project has potential issues. With .NET and Java you *know* you have patent issues, with D any potential patent issue is a tragic mistake that still has to be proven to exist. Those are not on the same scale, so I wouldn't use the term 'less trouble' You also have ownership to take into account, I would rather trust Walter Bright not using submarine patent traps than MS or Oracle :) I mostly agree with you :-) Maybe less trouble is not the right word.. my point is: I guess Walter did not explicitly try to avoid patents when developing D (and, as mentioned before, you can't be sure anyway), so you probably can't advertise D as a patent-free language (like ogg vorbis is claimed to be a patent-free audio codec). And I don't believe Walter is using any patent traps (Does he hold any patents? I wouldn't be surprised, and I don't really care because I don't believe he'd use it offensively) - but once D is popular you never know if a third party starts trolling. But of course, this may happen with any language or software in general. Furthermore, there was this thread in d.D about two Borland patents that are now owned by M$ that *may* be infringed by D... Perhaps I should elaborate a bit. mono is simply out of the question in a large part of linux. Fedora for example, has D as a feature for its 14 release but doesn't support mono. Java is more complex, but if we take it out of the picture it leaves (some of) linux with C / C++ on the one hand and a lot of higher level dynamic languages on the other. In between are some more 'exotic' languages such as haskell. Perhaps I'm wrong, but I see a big void there where D can step in, mostly because of its set of features. In the non-open-source world, Java and .NET are already taking care of much of this void. I agree. A free language that works well with C and is at least as user-friendly as Java definitely has a lot of potential in the open source and esp. Linux/*BSD world. Many Open Source developers will prefer it to Java/Mono, because it doesn't use a VM (some may still complain about the garbage collector, though, but in the end they'd benefit from it, because it mostly prevents the quite common memory leaks). Another thing that should be considered: For D2 to be really interesting in the Linux world, stream and socket handling needs to improve. But it seems like this will happen, Andrei started a discussion about a new std.stream in d.D recently. Cheers, - Daniel
Re: Build a D project is now easy
bioinfornatics schrieb: hello community, I have start a project for generate easily a build system for D project. Currently in d world everyone use his own build system for build a new project with a new system is a bit hard for everyone, for debug same thing. My tool generate makefile system for your project in one command: $ dmake --path src --lib src/myProject/ and for user he need ony do: $ make $ make install At this time only works for build a library. This system is usefull for support ldc, gdc and dmd compiler You can found the project here: http://gitorious.org/dmake/dmake Any help are welcome I think this is a good thing :-) D compilers are available in many linux distributions (debian, ubuntu and archlinux have gdc and ldc, fedora has ldc, don't know about other distributions), but D specific build-tools/systems like rebuild, dsss, xfbuild etc aren't. Make is part of any linux distribution, of course. So now you can use dmake to conveniently create a makefile so anybody who uses one of the aforementioned linux distributions can easily compile your software - he just needs to install [lg]dc and make from the distributions repository. This could really help any open source D application, because 1. they're painless to compile and install for users 2. your application being packaged in a linux distribution is more likely, because the build dependencies (well, at least the compiler and the make tool) already exist in the distribution Now all we need are killer open source applications written in D ;-) Cheers, - Daniel
Re: [Phoronix] Digital Mars Is Wanting To Merge D Into GCC
Jesse Phillips schrieb: Looks like Phoronix posted an article about D moving into GCC a couple weeks ago. So hopefully things are going well on this. http://www.phoronix.com/scan.php?page=news_itempx=ODc2Ng Phoronix took notice of D? Expect monthly articles revealing performance drawbacks in the latest beta versions of dmd/gdc/ldc that only matter in artificial benchmarks.
