Re: Oracle Database - ocilib
On 4/4/2012 9:47 AM, dnewbie wrote: On Tuesday, 3 April 2012 at 04:01:07 UTC, dnewbie wrote: It also works on Linux (I've just tested it on Debian Squeeze with Oracle Express) Rock'n'roll! Hi. I'd like to submit these bindings to be reviewed for inclusion in Deimos. Sure. For that I need a url of original C library, and a brief description.
Re: Russian TDPL is available for orders
On 05.04.2012 2:46, Igor Stepanov wrote: финиш Функциональные программисты убеждены, что такая модель вычислений поощряет неупорядоченное, параллельное выполнение, однако до недавнего времени эти возможности существовали скорее в виде потенциальной энергии, чем достигнутой цели. Так лучше? Да, неплохо. Меня все еще как-то тревожит в виде потенциальной энергии, чем достигнутой цели и мн. число в возможностях (все таки она одна - параллельное выполнение, остальное - эпитеты). Может быть лучше эта возможность являлась скорее потенциальной энергией, нежели достигнутой целью. -- Dmitry Olshansky
unzip parallel, 3x faster than 7zip
I uploaded a parallel unzip here, and the main in the examples folder. Testing on my ssd drive, unzips a 2GB directory structure in 17.5 secs. 7zip took 55 secs on the same file. This restores timestamps on the regular files. There is also a loop which will restore timestams on folders. It can be uncommented if the fix is added to std.file.setTimes that allows timestamp updates on folders. I documented a fix that I tested in issue 7819. https://github.com/jnorwood/file_parallel http://d.puremagic.com/issues/show_bug.cgi?id=7819 This has similar limitations to std.zip, Only does inflate or store, doesn't do decryption. There is a 4GB limit based on the 32 bit offsets limit of the zip format used. It processes 40MB blocks of files, and uses std.parallelism foreach loop. If the archived entry is larger than 40MB it will attempt to load it into memory, but there currently is no expansion technique in there to split a large single entry into blocks. I used the streams io to avoid the 2GB file limits still in stdio.
Re: unzip parallel, 3x faster than 7zip
On Thursday, 5 April 2012 at 14:04:57 UTC, Jay Norwood wrote: I uploaded a parallel unzip here, and the main in the examples folder. So, below is a demo of how to use the example app in windows, where I unzipped a 2GB directory structure from a 1GB zip file, tzip.zip. 02/18/2012 03:23 PMDIR test 03/30/2012 11:28 AM 968,727,390 tzip.zip 04/05/2012 08:07 AM 462,364 uzp.exe 03/21/2012 10:26 AM 1,603,584 wc.exe 03/06/2012 12:20 AMDIR xx8 13 File(s) 1,071,302,938 bytes 14 Dir(s) 49,315,860,480 bytes fre H:\uzp tzip.zip tz unzipping: .\tzip.zip finished! time: 17183 ms 02/18/2012 03:23 PMDIR test 04/05/2012 08:12 AMDIR tz 03/30/2012 11:28 AM 968,727,390 tzip.zip 04/05/2012 08:07 AM 462,364 uzp.exe 03/21/2012 10:26 AM 1,603,584 wc.exe 03/06/2012 12:20 AMDIR xx8 13 File(s) 1,071,302,938 bytes 15 Dir(s) 47,078,543,360 bytes free The example supports several forms of commandline: uzp zipFilename to unzip in current folder, or uzp zipFilename destFoldername to unzip into the destination folder, or uzp zipf1 zipf2 zipf3 destFoldername to unzip multiple zip files to dest folder, or uzp zipf* destFoldername to unzip multiple zip files (wildarg expansion)to dest folder It overwrites existing directory entries without asking in the current form.
Re: Oracle Database - ocilib
On Thursday, 5 April 2012 at 06:15:59 UTC, Walter Bright wrote: On 4/4/2012 9:47 AM, dnewbie wrote: On Tuesday, 3 April 2012 at 04:01:07 UTC, dnewbie wrote: It also works on Linux (I've just tested it on Debian Squeeze with Oracle Express) Rock'n'roll! Hi. I'd like to submit these bindings to be reviewed for inclusion in Deimos. Sure. For that I need a url of original C library, and a brief description. Description (from sourceforge.net project page) OCILIB is an open source and cross platform Oracle Driver that delivers efficient access to Oracle databases. It offers a full featured, easy and productive API. Written in ISO C on top of OCI, OCILIB runs on all Oracle platforms. Official website: http://www.ocilib.net/ Sourceforge project: http://sourceforge.net/projects/orclib/ Wikipedia: http://en.wikipedia.org/wiki/OCILIB
Re: unzip parallel, 3x faster than 7zip
On Thursday, 5 April 2012 at 15:07:47 UTC, Jay Norwood wrote: so, a few comments about std.zip... I attempted to use it and found that its way of unzipping is a memory hog, keeping the full original and all the unzipped data in memory. It quickly ran out of memory on my test case. The classes didn't lend themselves to parallel execution, so I broke them into a few pieces ... one creates the directory structure, one reads in compressed archive entries, one expands archive entries. The app creates the directory structure non-parallel using the mkdir recursive. I found that creating the directory structure only took about 0.4 secs of the total time in that 2GB test. I found that creating the directory structure, reading the zip entries, and expanding the data, without writing to disk, took less than 4 secs, with the expansion done in parallel. The other 13 to 14 secs were all taken up by writing out the files, with less than a half sec of that required to update the timestamps. This is on about 39k directory entries. The 17 sec result is on the intel 510 series ssd drive. on a hard drive 7zip took 128 secs and uzp took about 70 sec. G:\uzp tzip.zip tz unzipping: .\tzip.zip finished! time: 69440 ms It is interesting that win7 takes longer to delete these directories than it does to create them.
Re: unzip parallel, 3x faster than 7zip
Am 05.04.2012 16:04, schrieb Jay Norwood: I uploaded a parallel unzip here, and the main in the examples folder. Testing on my ssd drive, unzips a 2GB directory structure in 17.5 secs. 7zip took 55 secs on the same file. it makes no sense to benchmark different algorithm zip-7zip compare only unzip and parallel unzip - nothing else makes sense
Re: unzip parallel, 3x faster than 7zip
On 04/05/2012 06:37 PM, dennis luehring wrote: Am 05.04.2012 16:04, schrieb Jay Norwood: I uploaded a parallel unzip here, and the main in the examples folder. Testing on my ssd drive, unzips a 2GB directory structure in 17.5 secs. 7zip took 55 secs on the same file. it makes no sense to benchmark different algorithm zip-7zip compare only unzip and parallel unzip - nothing else makes sense I think he is talking about 7zip the standalone software, not 7zip the compression algorithm. 7zip took 55 secs _on the same file_.
Re: Oracle Database - ocilib
On 4/5/2012 8:08 AM, dnewbie wrote: Description (from sourceforge.net project page) OCILIB is an open source and cross platform Oracle Driver that delivers efficient access to Oracle databases. It offers a full featured, easy and productive API. Written in ISO C on top of OCI, OCILIB runs on all Oracle platforms. Official website: http://www.ocilib.net/ Sourceforge project: http://sourceforge.net/projects/orclib/ Wikipedia: http://en.wikipedia.org/wiki/OCILIB https://github.com/D-Programming-Deimos/ocilib
Re: OSCON 2012 session: Generic Programming Galore using D
On 4/3/2012 7:59 AM, Andrei Alexandrescu wrote: I'm not sure, but recording conferences is quickly becoming the default. Which is really cool. Having attended many conferences, often the really good stuff is going on in the halls. So I am always faced with do I attend the presentation, or do I continue this great discussion with smart people I've never had the chance to talk to before? Knowing that they're recorded and if I miss a great one, I can always look at it later, makes it an easier decision.
Re: unzip parallel, 3x faster than 7zip
I think he is talking about 7zip the standalone software, not 7zip the compression algorithm. 7zip took 55 secs _on the same file_. Yes, that's right, both 7zip and this uzp program are using the same deflate standard format of zip for this test. It is the only expand format that is supported in std.zip. 7zip was used to create the zip file used in the test. 7zip already has multi-core compression capability, but no multi-core uncompress. I haven't seen any multi-core uncompress for deflate format, but I did see one for bzip2 named pbzip2. In general, though, inflate/deflate are the fastest algorithms I've seen, when comparing the ones that are available in 7zip. I'm happy with the 7zip performance on compress with the inflate format, but not on the uncompress, so I will be using this uzp app. I'm curious why win7 is such a dog when removing directories. I see a lot of disk read activity going on which seems to dominate the delete time. This doesn't make any sense to me unless there is some file caching being triggered on files being deleted. I don't see any virus checker app being triggered ... it all seems to be system read activity. Maybe I'll try non cached flags, write truncate to 0 length before deleting and see if that results in faster execution when the files are deleted...
Re: Oracle Database - ocilib
On Thursday, 5 April 2012 at 17:58:15 UTC, Walter Bright wrote: https://github.com/D-Programming-Deimos/ocilib Thank you.
Re: DMD asserts using delegate and type inference
On 2012-04-05 08:19, Walter Bright wrote: On 4/3/2012 10:00 AM, Jacob Carlborg wrote: When I try to use a delegate as template parameter and type inference DMD asserts with this message: Assertion failed: (!vthis-csym), function toObjFile, file glue.c, line 686. Assertion fails are compiler bugs. Please submit them to bugzilla: http://d.puremagic.com/issues/enter_bug.cgi?product=D Done: http://d.puremagic.com/issues/show_bug.cgi?id=7827 -- /Jacob Carlborg
Re: DIP16: Transparently substitute module with package
Le 05/04/2012 02:55, Martin Nowak a écrit : What happen if both pkg.d and pkg/_.d exists ? If it is not in the same path (think -I compiler option). In one case, this is an issue, in the other this isn't. pkg.d would always be a module, hence result in a module/package conflict. We'd need to directly search for a subdirectory to decide whether it's a package. This is true, but why would it be a conflict ? Package already is a tree structure, so it shouldn't cause much trouble. Maybe someone with experience of big Python projects has some valuable insights, but I think one point of adding the file inside a folder is to prevent from unintended pickup of folders. Using eponymous trick, you'd always pick up a file, never a folder. Hence, lookup rules get easier. Plus it is D-ish. I have no doubt that this approach is working in python, and could work in D. This is exactly why this was my first proposal. But this doesn't means that we can't do better. I have tested quite a lot of way to achieve that, in several languages, and this is usually a messy topic, with no single solution.
DMD compiler switch to set default extern() linkage?
Hi, It is no secret that DMD is the only compiler in existence that follows the D calling convention (and even then, only on some platforms, seemingly?). Both GDC and LDC use the C calling convention of the platform by default (and don't even have options to use the D calling convention because their back ends don't support it at all). I'm writing a virtual machine. As far as I am concerned, the D calling convention adds nothing but complexity to the configuration support matrix. The calling convention situation across platforms is already utterly insane enough as it is. I would not have a problem with supporting the D calling convention if all compilers followed it. But they don't. And it is only specified for x86. Even in an ideal world, the D calling convention won't exist everywhere because it isn't intended to. So yes, we could just say but eventually, those compilers should support it!. But realistically, it is not going to happen. Those compilers have no reason to implement yet another calling convention that is entirely specific to x86. I don't think it's good that DMD forces all functions to use the D calling convention by default. However, I accept that it is an established situation, and changing is now is not an option. That said, I believe a compiler switch to set the default extern() linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d Thoughts? -- - Alex
Re: Poll of the week - How long have you been in the D world?
In my case, D is just one of the new upcoming languages group that I lurk around as a language geek. Besides playing with the language in toy projects, there isn't much I can do with it, as on my line of work only JVM/.NET languages are allowed, with some luck I get to touch C++ every now and then. -- Paulo Stewart Gordon wrote in message news:jl7pq6$2uot$1...@digitalmars.com... On 31/03/2012 05:25, Chris NS wrote: snip Some of us are -- though I don't know how many are actually still D1 people per se... I'd say most have made the jump by now. What I feel from the numbers is simply that we have a mostly steady rate of community growth. Depends what you mean by community. It's really a matter of how many people answered the poll. The proportion the sample represents of the total number of D programmers is liable to get smaller as D becomes an ISO/ANSI/whatever standard, gains more and more third-party compilers and is adopted by more and more businesses, since many of the users will not be coming through Digital Mars and so are less likely to be active on these 'groups. And so, in the long run, the poll results are likely to understate the growth in the number of D users. Though publicising the poll in as many D-related forums as we can find will help to counter this Stewart.
Re: DMD compiler switch to set default extern() linkage?
Le 05/04/2012 11:49, Alex Rønne Petersen a écrit : Hi, It is no secret that DMD is the only compiler in existence that follows the D calling convention (and even then, only on some platforms, seemingly?). Both GDC and LDC use the C calling convention of the platform by default (and don't even have options to use the D calling convention because their back ends don't support it at all). I'm writing a virtual machine. As far as I am concerned, the D calling convention adds nothing but complexity to the configuration support matrix. The calling convention situation across platforms is already utterly insane enough as it is. I would not have a problem with supporting the D calling convention if all compilers followed it. But they don't. And it is only specified for x86. Even in an ideal world, the D calling convention won't exist everywhere because it isn't intended to. So yes, we could just say but eventually, those compilers should support it!. But realistically, it is not going to happen. Those compilers have no reason to implement yet another calling convention that is entirely specific to x86. I don't think it's good that DMD forces all functions to use the D calling convention by default. However, I accept that it is an established situation, and changing is now is not an option. That said, I believe a compiler switch to set the default extern() linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d Thoughts? Extern(XXX) change the calling convention, but also the mangling. Setting it by default would create a huge mess. It is, for example, sure to create massive mangled name collision if extern(C) is applied by default (C doesn't mangle argument types and doesn't support modules). I understand the issue, but the solution would be a switch to force ABI, not extern.
Re: DMD compiler switch to set default extern() linkage?
On 05-04-2012 12:02, deadalnix wrote: Le 05/04/2012 11:49, Alex Rønne Petersen a écrit : Hi, It is no secret that DMD is the only compiler in existence that follows the D calling convention (and even then, only on some platforms, seemingly?). Both GDC and LDC use the C calling convention of the platform by default (and don't even have options to use the D calling convention because their back ends don't support it at all). I'm writing a virtual machine. As far as I am concerned, the D calling convention adds nothing but complexity to the configuration support matrix. The calling convention situation across platforms is already utterly insane enough as it is. I would not have a problem with supporting the D calling convention if all compilers followed it. But they don't. And it is only specified for x86. Even in an ideal world, the D calling convention won't exist everywhere because it isn't intended to. So yes, we could just say but eventually, those compilers should support it!. But realistically, it is not going to happen. Those compilers have no reason to implement yet another calling convention that is entirely specific to x86. I don't think it's good that DMD forces all functions to use the D calling convention by default. However, I accept that it is an established situation, and changing is now is not an option. That said, I believe a compiler switch to set the default extern() linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d Thoughts? Extern(XXX) change the calling convention, but also the mangling. Setting it by default would create a huge mess. It is, for example, sure to create massive mangled name collision if extern(C) is applied by default (C doesn't mangle argument types and doesn't support modules). I understand the issue, but the solution would be a switch to force ABI, not extern. OK, so what we really want is an option to specify what calling convention to use when extern(D) is used. Something like: dmd -cc=C/D foo.d -- - Alex
Re: DMD compiler switch to set default extern() linkage?
On 05.04.2012 13:49, Alex Rønne Petersen wrote: Hi, It is no secret that DMD is the only compiler in existence that follows the D calling convention (and even then, only on some platforms, seemingly?). IMHO It's the only sane convention I've seen. C's default of caller-side cleanup adds nothing but a mess for years to clean up. And code size bloat for no good reason. I think it was just a cool trick to make printf work, bleh. And extern(D) still allows that. Both GDC and LDC use the C calling convention of the platform by default (and don't even have options to use the D calling convention because their back ends don't support it at all). I'm writing a virtual machine. As far as I am concerned, the D calling convention adds nothing but complexity to the configuration support matrix. The calling convention situation across platforms is already utterly insane enough as it is. I would not have a problem with supporting the D calling convention if all compilers followed it. But they don't. And it is only specified for x86. Even in an ideal world, the D calling convention won't exist everywhere because it isn't intended to. So yes, we could just say but eventually, those compilers should support it!. Yup, let's stop being kids and copying whatever big ones are doing. Standards sort of happen like this: people just start doing things differently, then others like it and follow suit and then it's all written on a bunch (virtual) paper with ISO number somewhere. But realistically, it is not going to happen. Those compilers have no reason to implement yet another calling convention that is entirely specific to x86. Extend it, I've seen some movement on ARM side. I don't think it's good that DMD forces all functions to use the D calling convention by default. However, I accept that it is an established situation, and changing is now is not an option. That said, I believe a compiler switch to set the default extern() linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d Thoughts? -- Dmitry Olshansky
Re: DMD compiler switch to set default extern() linkage?
On 05-04-2012 12:16, Dmitry Olshansky wrote: On 05.04.2012 13:49, Alex Rønne Petersen wrote: Hi, It is no secret that DMD is the only compiler in existence that follows the D calling convention (and even then, only on some platforms, seemingly?). IMHO It's the only sane convention I've seen. C's default of caller-side cleanup adds nothing but a mess for years to clean up. And code size bloat for no good reason. I think it was just a cool trick to make printf work, bleh. And extern(D) still allows that. Right. I won't deny that the D calling convention is good, but supporting it is not practical. Both GDC and LDC use the C calling convention of the platform by default (and don't even have options to use the D calling convention because their back ends don't support it at all). I'm writing a virtual machine. As far as I am concerned, the D calling convention adds nothing but complexity to the configuration support matrix. The calling convention situation across platforms is already utterly insane enough as it is. I would not have a problem with supporting the D calling convention if all compilers followed it. But they don't. And it is only specified for x86. Even in an ideal world, the D calling convention won't exist everywhere because it isn't intended to. So yes, we could just say but eventually, those compilers should support it!. Yup, let's stop being kids and copying whatever big ones are doing. Standards sort of happen like this: people just start doing things differently, then others like it and follow suit and then it's all written on a bunch (virtual) paper with ISO number somewhere. Good luck convincing the GCC guys to merge your D ABI patch. ;) But realistically, it is not going to happen. Those compilers have no reason to implement yet another calling convention that is entirely specific to x86. Extend it, I've seen some movement on ARM side. Extend what? I don't think it's good that DMD forces all functions to use the D calling convention by default. However, I accept that it is an established situation, and changing is now is not an option. That said, I believe a compiler switch to set the default extern() linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d Thoughts? -- - Alex
Re: Poll of the week - How long have you been in the D world?
On 05/04/2012 10:49, Paulo Pinto wrote: In my case, D is just one of the new upcoming languages group that I lurk around as a language geek. Besides playing with the language in toy projects, there isn't much I can do with it, as on my line of work only JVM/.NET languages are allowed, with some luck I get to touch C++ every now and then. snip There was a D.NET in the works a few years ago. Last post about it seems to have been on .announce in May 2009. Does anyone know what's happened to it since? Stewart.
Re: DMD compiler switch to set default extern() linkage?
On 05/04/12 11:49, Alex Rønne Petersen wrote: Hi, It is no secret that DMD is the only compiler in existence that follows the D calling convention (and even then, only on some platforms, seemingly?). Both GDC and LDC use the C calling convention of the platform by default (and don't even have options to use the D calling convention because their back ends don't support it at all). There are couple of separate issues here, I think. The most important issue is the name mangling. That MUST be supported by all compilers, on all platforms. The binary layout of objects MUST also be consistent across a processor. If any currently don't obey this, it's a bug. That leaves parameter passing conventions, which are indeed a problem. There are a couple of DMD oddities, like passing the last parameter in EAX. The DMD calling convention is not particularly efficient. It's just plain weird. The whole thing is rather peculiar because different OSes impose different restrictions -- eg, stack has to be aligned on OSX, Linux64 and Windows64 are radically different -- so it isn't even possible to be identical on all systems. I'm writing a virtual machine. As far as I am concerned, the D calling convention adds nothing but complexity to the configuration support matrix. The calling convention situation across platforms is already utterly insane enough as it is. I would not have a problem with supporting the D calling convention if all compilers followed it. But they don't. And it is only specified for x86. Even in an ideal world, the D calling convention won't exist everywhere because it isn't intended to. So yes, we could just say but eventually, those compilers should support it!. But realistically, it is not going to happen. Those compilers have no reason to implement yet another calling convention that is entirely specific to x86. I don't think it's good that DMD forces all functions to use the D calling convention by default. However, I accept that it is an established situation, and changing is now is not an option. That said, I believe a compiler switch to set the default extern() linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d Thoughts?
Re: DIP16: Transparently substitute module with package
On Wed, 04 Apr 2012 20:50:49 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-04-04 19:48:32 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
No symbol is resolved until semantic, but I don't think hiding the
module/package symbol if any clashing symbol in the module/any
subpackage exists is a satisfactory solution.
Then we must come up with a way to hide the submodules of a virtual
module.
I tried this, which fails on the current compiler:
import x;
int x;
So it seems we have two choices here:
1. DIP16 needs to get more complex to make package submodules not
accesible as individual modules.
2. Start contextually interpreting identifiers at least in the case of
modules vs. non-modules.
I'd suggest option 2 allows for better backwards compatibility and
more flexibility.
I don't think option 2 is realistic (see my other post).
I saw your other post. I see that a major issue with the way DIP16
intends to shortcut fully qualified names is demonstrated by this simple
example:
a/b/c.d:
module a.b.c;
void foo() {}
struct c
{
static void foo() {}
}
main.d:
import a.b.c;
void main()
{
a.b.c.foo(); // cannot determine what this is. Is it the global
function, or a shortcut FQN to a.b.c.c.foo?
}
This should be counter-case enough to disqualify that idea -- it will
break existing code without ever adding any package.d files. Thanks for
explaining.
I don't think option 1 is an improvement over what we have. I mean, if
you're going to hide the submodules, what is the benefit compared to
just using a different package name for the implementation modules?
The advantage is you can split your logical module into submodules for
maintenance purposes.
You can already refactor std.algorithm this way with no change in the
compiler:
module std.algorithm;
public import std.algorithm_impl.sort;
public import std.algorithm_impl.map;
public import std.algorithm_impl.blah_blah_blah;
…
If we add a language feature, it should be an noticeable improvement
over this situation.
I agree, option 1 is not very convincing.
I think we need a third option.
Here's an idea: we could allow modules having a single symbol with the
same name as the module to behave as if they were the symbol itself,
just like templates behaves. For instance:
module std.algorithm.sort;
void sort(int[] t);
Now you can import std.algorithm.sort and then use the
std.algorithm.sort fully qualified name as if it was a function, even
though it's the module name (std.algorithm.sort.sort would be the
function's name).
Or maybe we could just allow alias sort this at module level? Or is it
allowed already?
I don't like this proposal, simply because this means one function/symbol
per submodule. It should be more flexible than that. But I like the line
of thinking.
Let's re-examine the issue. We need to allow splitting of a module X.d
into pieces for maintenance (or possibly accessibility -- disallowing
friends). But we don't want to break code which currently uses FQN to
access X's symbols.
I think the following might work:
algorithm.d:
import this = std.algorithm_impl.sort;
Which then imports std.algorithm_impl.sort, and effectively aliases all
its symbols into algorithm.d. If std.algorithm_impl.sort defines a
function called sort, then it's also aliased to std.algorithm.sort. In
essence, sort has *two* FQN, but there are no FQN that refer to more than
one symbol.
I purposely left out the package.d idea because it's orthogonal to this.
-Steve
Unicode, graphemes and D
For people interested in a better Unicode handling in D, I have seen that Perl has some support for graphemes, /\X/ matches an extended grapheme cluster: http://perldoc.perl.org/perl5120delta.html#Unicode-overhaul http://perldoc.perl.org/perluniprops.html Perl seems one of the best languages to manage Unicode (D and Go too are good): http://rosettacode.org/wiki/String_length#Grapheme_Length_2 Bye, bearophile
Re: Custom attributes (again)
Manu, as a workaround would marker interfaces help to solve your problem for the time being? This is just a suggestion for the time being, as I agree with you, attributes/annotations are quite handy. -- Paulo Manu turkey...@gmail.com wrote in message news:mailman.1363.1333627256.4860.digitalmar...@puremagic.com... I just want to add more real-world experience to the controversy. I'm finding myself needing to use custom attributes almost every day. I have numerous systems that need to scan the module for things marked accordingly to automate bindings to their respective systems. This is my current list of attributes I want to mark things with: Export to game engine Export to script language Import from game engine ** Import from script language (tentative, I'm sure I'll need it in a few more days) Expose to editor (with additional properties; description, edit type, etc) Serialise (load/save game) Replay serialisation (a different kind of serialisation that works with different data sets) And others I've encountered in passing that I can't recall right now. As you can imagine, any attempt to 'work around' the lack of an attribute system, ie, (ab)using enums, etc as have been suggested, leads to a big mess in the context of all these requirements. Management of such lists of stuff in disconnected places in code is time consuming, thoroughly annoying, error-prone, difficult to maintain, and leaves programmers with the bitter taste of C++. Alternatively, wrapping virtually every single declaration made in mixin() and declaring everything as strings is even more nasty, and the contrast between mixin() declarations and 'normal' declarations looks completely stupid. (Totally unreadable + difficult to understand, breaks intellisense, code completion, syntax hilighting, etc... ie, unusable) Does anyone have a *realistic* suggestion for emulating custom attributes? Something that doesn't have any(/many) of the side effects I mention? I haven't come up with anything that's acceptable yet. If not, I assert that D absolutely needs a custom attribute system. For us here, this will enable D the single biggest advantage over using C++ in the same context that I've identified so far. D's meta-programming is amazing, but sadly, proving pointless to me right now without being able to mark stuff appropriately. All the meta magic is hovering just out of my grasp, due to the fact I have no way to indicate what items should involve with what systems. Currently, I have to maintain big registry tables of junk that must be amended/updated any time anyone adds/changes anything... and I'm feeling rather embarrassed when I tell the other non-D programmers that they just need to update this table here... and here... and make sure that's in sync too before their stuff will just 'magically' work ;) C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented.
Re: Unicode, graphemes and D
On 05.04.2012 15:53, bearophile wrote: For people interested in a better Unicode handling in D, I have seen that Perl has some support for graphemes, /\X/ matches an extended grapheme cluster: http://perldoc.perl.org/perl5120delta.html#Unicode-overhaul http://perldoc.perl.org/perluniprops.html Perl seems one of the best languages to manage Unicode (D and Go too are good): http://rosettacode.org/wiki/String_length#Grapheme_Length_2 Bye, bearophile FYI http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002# -- Dmitry Olshansky
Re: Custom attributes (again)
On 5 April 2012 15:04, Paulo Pinto pj...@progtools.org wrote: as a workaround would marker interfaces help to solve your problem for the time being? I don't think it'd suit my purposes implemented as an interface for a variety of reasons: I need to be able to attribute many different types of things; data members, static functions, methods, etc. I need to be able to annotate 'loose' things at module scope. The whole point of the system is that it doesn't enforce a rigid interface. From my examples above, these items could be basically anything, anywhere.
Re: Custom attributes (again)
On 4/5/12, Manu turkey...@gmail.com wrote: Does anyone have a *realistic* suggestion for emulating custom attributes? Something that doesn't have any(/many) of the side effects I mention? I haven't come up with anything that's acceptable yet. Not too sure. QtD has some sort of attribute system, it might be worth looking into (https://bitbucket.org/qtd/repo) If not, I assert that D absolutely needs a custom attribute system. Well apparently this is already agreed upon, but nobody knows how to implement it yet: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Re: Custom attributes (again)
Paulo Pinto: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. There are other interesting ways to conceive attributes. I think of them in a different way, more like user-defined ways to extend the static type system. Bye, bearophile
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix deadal...@gmail.com wrote: If such a syntax is adopted, what would be the point of public imports ? If it is still useful, then your syntax is a better choice, otherwise, we'd better modify public import. Another way to look at it: A public import saves you from having to import dependent modules that you should be importing anyway. A 'this' import treats the other modules as if they were actually part of the imported module in terms of namespace. To give an example, std.range imports std.array. std.array is a module all on its own, and has a specific set of functionality. std.range has a different set of functionality, but you would never want to have std.range imported without also importing std.array. Another example would be a derived class module publicly importing the base class module. On the other hand, something like std.container could have 15 different container types in it. Each of these container types should really live in their own module, in terms of maintenance and separation of private data. For example, std.container.RedBlackTree has no business accessing the private members of std.container.Array. But because they live in the same module, it can. However, we don't want to define std.container.RedBlackTree.RedBlackTree in terms of namespace. So we have one of these combining modules, and everything still lives in the std.container namespace, but we get all the benefits of separating the code into individual modules. -Steve
Re: Custom attributes (again)
On 5 April 2012 15:46, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 4/5/12, Manu turkey...@gmail.com wrote: Does anyone have a *realistic* suggestion for emulating custom attributes? Something that doesn't have any(/many) of the side effects I mention? I haven't come up with anything that's acceptable yet. Not too sure. QtD has some sort of attribute system, it might be worth looking into (https://bitbucket.org/qtd/repo) Hmm, that's very un-cool, but I think it's definitely better than what I have. I might try something like that out and see how I go. If not, I assert that D absolutely needs a custom attribute system. Well apparently this is already agreed upon, but nobody knows how to implement it yet: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Wow, August 2009. Interesting that it tends to be so controversial in that case :)
Re: DIP16: Transparently substitute module with package
On 04/05/2012 02:58 PM, Steven Schveighoffer wrote: No, public imports simply mean that you can view the publicly imported module. It does *not* add aliases to the importing module. Have you tried it?
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch wrote: On 04/05/2012 02:58 PM, Steven Schveighoffer wrote: No, public imports simply mean that you can view the publicly imported module. It does *not* add aliases to the importing module. Have you tried it? I just did. OK, what the hell are we arguing about then?! DIP16 is worksforme :) See this part of the spec: http://dlang.org/module.html Read the part on public modules. You may understand why I didn't know about that feature (which seems to work on all the installed compilers I have, back to 2.033). I just read the public import part of TDPL, and there it is, all spelled out quite nicely. I'm going to file a bug against the spec... grrr... I'm now firmly in the we don't need to change anything, just refactor the modules and use public import camp. We don't even need to change ANYTHING in the compiler! Forget everything I said before in this thread ;) I suppose the only thing we don't get is being able to have a module and a package with the same FQN. I don't see that being a major issue. -Steve
Re: GSoC 2012 Proposal: Continued Work on a D Linear Algebra library (SciD - std.linalg)
Thanks for the explanation, now I get it. In case you are interested,
there is excellent article about monad style c++ template meta
programming by Bartosz Milewski which might be helpful for compile
time optimization for evaluation order.
Really looking forward to official release of the SciD. D is really
suitable for scientific computation. It will be great to have an
efficient and easy-to-use linear algebra library.
On Thu, Apr 5, 2012 at 7:42 AM, Cristi Cobzarenco
cristi.cobzare...@gmail.com wrote:
Thanks for the feedback!
On 4 April 2012 10:21, Michael Chen sth4...@gmail.com wrote:
another btw, there is also another great c++ linear algebra library
besides Eigen: Amardillo which has very simple matlab like interface
and performs on a par with Eigen.
I'll look into it, thanks.
On Wed, Apr 4, 2012 at 5:14 PM, Michael Chen sth4...@gmail.com wrote:
Btw, I really don't like the matrix api to be member functions. It is
hard for user to extend the library in an unified way. It is also ugly
when you want to chain the function calls.
On Wed, Apr 4, 2012 at 5:09 PM, Michael Chen sth4...@gmail.com wrote:
For the Point 4, I really like to have high order functions like
reduceRow and reduceCol. then the function argument is simply the
reduceRow!foo(0,mat), here the foo is not a function operating on the
whole column but simply a function of two elements (e.g.
reduceRow!(a+b)(0,mat)). Or even better we could have a general
reduce function with row and col as template parameter so that we can
do reduce!(foo,row)(0,mat). I dont know whether we can optimize such
reduce function for different matrix type, but such a function will be
extremely useful from a user perspective
Well, as I said before, there's nothing stopping us from providing the free
functions that call the member functionsl. However there is something
stopping us from not providing a member function alternative. D's lack of
ADL means we would not allow easy extensibility of possible operations. Say
Alice invents a new kind of matrix type, the DiagonalMatrix type which
stores its elements in a 1D array (this isn't exactly how it would work with
the design we have, she would in fact have to define a storage type, but
bear with me). If she wants to implement sum on her matrix, she can't simply
add a specialisation to the sum( T ) function because of the lack of ADL. If
instead we implemented sum(T) as:
auto sum( T )( T matrix ) {
static if( is( typeof( T.init.sum() ) ) )
return matrix.sum;
else
return reduce!a+b( 0, matrix.elements() );
}
then Alice could simply define a DiagonalMatrix.sum() method that wouldn't
need to go through all the zero elements, for example. The idea of rowReduce
and columnReduce still works - we can provide this for when a user wants to
use her own operation for reducing. We could also have a way of
automatically optimising rowReduce!a+b( mat ) by calling
mat.rowwise().sum() if the operation is available - but that wouldn't be
exactly high priority.
.
On Tue, Apr 3, 2012 at 7:20 PM, Cristi Cobzarenco
cristi.cobzare...@gmail.com wrote:
On 3 April 2012 02:37, Caligo iteronve...@gmail.com wrote:
I've read **Proposed Changes and Additions**, and I would like to
comment and ask a few questions if that's okay. BTW, I've used Eigen
a lot and I see some similarities here, but a direct rewrite may not
be the best thing because D C++.
2. Change the matrix vector types, adding fixed-sized matrix
support in the process.
This is a step in the right direction I think, and by that I'm
talking
about the decision to remove the difference between a Vector and a
Matrix. Also, fixed-size matrices are also a must. There is
compile-time optimization that you won't be able to do for
dynamic-size matrices.
3. Add value arrays (or numeric arrays, we can come up with a good
name).
I really don't see the point for these. We have the built-in arrays
and the one in Phobos (which will get even better soon).
The point of these is to have light-weight element wise operation
support.
It's true that in theory the built-in arrays do this. However, this
library
is built on top BLAS/LAPACK, which means operations on large matrices
will
be faster than on D arrays. Also, as far as I know, D doesn't support
allocating dynamic 2-D arrays (as in not arrays of arrays), not to
mention
2-D slicing (keeping track of leading dimension).
Also I'm not sure how a case like this will be compiled, it may or may
not
allocate a temporary:
a[] = b[] * c[] + d[] * 2.0;
The expression templates in SciD mean there will be no temporary
allocation
in this call.
4. Add reductions, partial reductions, and broadcasting for matrices
and
arrays.
This one is similar to what we have in Eigen, but I don't understand
why the operations are member functions (even in Eigen). I
Re: Poll of the week - How long have you been in the D world?
On Thursday, 5 April 2012 at 10:50:18 UTC, Stewart Gordon wrote: There was a D.NET in the works a few years ago. Last post about it seems to have been on .announce in May 2009. Does anyone know what's happened to it since? He had a very ambitious plan to compile phobos. That was too bold to work.
Re: DIP16: Transparently substitute module with package
Le 05/04/2012 14:58, Steven Schveighoffer a écrit :
On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix deadal...@gmail.com wrote:
Le 05/04/2012 13:46, Steven Schveighoffer a écrit :
I don't like this proposal, simply because this means one
function/symbol per submodule. It should be more flexible than that. But
I like the line of thinking.
Let's re-examine the issue. We need to allow splitting of a module X.d
into pieces for maintenance (or possibly accessibility -- disallowing
friends). But we don't want to break code which currently uses FQN to
access X's symbols.
I think the following might work:
algorithm.d:
import this = std.algorithm_impl.sort;
Which then imports std.algorithm_impl.sort, and effectively aliases all
its symbols into algorithm.d. If std.algorithm_impl.sort defines a
function called sort, then it's also aliased to std.algorithm.sort. In
essence, sort has *two* FQN, but there are no FQN that refer to more
than one symbol.
I purposely left out the package.d idea because it's orthogonal to this.
-Steve
The behavior you described has been proposed for public import, and
have been discussed. This is interesting.
You propose an alternative syntax with is fine and have the advantage
to not disturb already existing public imports, but have the drawback
to create a new syntax, again.
If such a syntax is adopted, what would be the point of public imports
? If it is still useful, then your syntax is a better choice,
otherwise, we'd better modify public import.
No, public imports simply mean that you can view the publicly imported
module. It does *not* add aliases to the importing module.
for example:
foo.d:
module foo;
int x;
bar.d:
module bar;
public import foo;
int y;
main.d:
import bar; // publicly imports foo.
void main()
{
foo.x = 5; // ok, publicly imported via bar (non public, this would be
an error)
bar.y = 5; // ok
bar.x = 5; // error, public import doesn't create new fully qualified
name for foo.x
}
With the system I propose, using the specific technique would make it so
bar.x would also be valid, and would refer to foo.x
I think we need new syntax, or a new language feature, because you don't
want to alter the operation of existing code. Simply changing public
imports would cause lots of existing code to be reinterpreted, possibly
in a way not intended, or that would be ambiguous.
-Steve
I know. I think you answered too fast.
I wasn't stating that public import are the same as what you propose. I
was discussing the fact that both probably answer the same need and that
2 different syntax is something to avoid.
Code wouldn't be broken in unexpected way, because thing will cause
either a compile error (collision of names, but the problem exists with
other solutions too) or is illegal in the current shape of the language.
Re: Custom attributes (again)
Le 05/04/2012 15:23, Manu a écrit : I might try something like that out and see how I go. If not, I assert that D absolutely needs a custom attribute system. Well apparently this is already agreed upon, but nobody knows how to implement it yet: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Wow, August 2009. Interesting that it tends to be so controversial in that case :) This describe how annotations would be used, not how they are created, so it is pretty useless.
Re: DIP16: Transparently substitute module with package
On 2012-04-05 11:46:38 +, Steven Schveighoffer schvei...@yahoo.com said: I don't like this proposal, simply because this means one function/symbo l per submodule. It should be more flexible than that. But I like the li ne of thinking. I have the same reserve about it's lack of flexibility too. It would be a nice thing to have for all those libraries having one module per class as it'd reduce the length of the fully qualified name you have to use when you need to disambiguate. But for moving a module like std.algorithm to a package, it's cumbersome. Let's re-examine the issue. We need to allow splitting of a module X.d into pieces for maintenance (or possibly accessibility -- disallowing friends). But we don't want to break code which currently uses FQN to access X's symbols. I think the following might work: algorithm.d: import this = std.algorithm_impl.sort; Which then imports std.algorithm_impl.sort, and effectively aliases all its symbols into algorithm.d. If std.algorithm_impl.sort defines a function called sort, then it's also aliased to std.algorithm.sort. In essence, sort has *two* FQN, but there are no FQN that refer to more tha n one symbol. This is what a public import should do. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DIP16: Transparently substitute module with package
On 4/4/12 10:53 AM, Steven Schveighoffer wrote: On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin michel.for...@michelf.com wrote: Question 2: does std.algorithm.sort refer to the std.algorithm.sort *module* or to std.algorithm.package.sort *function* publicly imported from the std.algorithm.sort module? The function. A symbol that is not specified as the module name in import statement or in a module statement is always *not* a module. I think our one saving grace here is that when you want to import a specific symbol from a module, this is not the syntax: import std.stdio.writefln; So there is never any ambiguity as to whether you mean a module identifier or other symbol. Interesting. But isn't there an ambiguity when the symbol is not the last one in the chain? Consider: a.b.c.x Could be static member d of class c in module a.b, or module member d in module a.b.c. Andrei
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 10:26:16 -0400, deadalnix deadal...@gmail.com wrote: Le 05/04/2012 14:58, Steven Schveighoffer a écrit : On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix deadal...@gmail.com wrote: Le 05/04/2012 13:46, Steven Schveighoffer a écrit : No, public imports simply mean that you can view the publicly imported module. It does *not* add aliases to the importing module. [snip] I know. I think you answered too fast. I wasn't stating that public import are the same as what you propose. I was discussing the fact that both probably answer the same need and that 2 different syntax is something to avoid. Code wouldn't be broken in unexpected way, because thing will cause either a compile error (collision of names, but the problem exists with other solutions too) or is illegal in the current shape of the language. My assertion above is 100% *WRONG*. See this bug I just filed. http://d.puremagic.com/issues/show_bug.cgi?id=7830 In fact public imports today are *exactly* the same as what I proposed. I had no idea. I think we are (well, at least I am) on a wild goose chase here. All that is left to discuss is if/how we want to allow importing of packages. But I think DIP15 already covers that http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15 I think DIP16 is worksforme/invalid, and should be closed. -Steve
Re: Custom attributes (again)
On Thursday, 5 April 2012 at 12:46:46 UTC, Andrej Mitrovic wrote: Well apparently this is already agreed upon, but nobody knows how to implement it yet: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Looks like DIP6 is already implemented in the form of @safe and @trusted attributes.
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 10:35:52 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/4/12 10:53 AM, Steven Schveighoffer wrote: On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin michel.for...@michelf.com wrote: Question 2: does std.algorithm.sort refer to the std.algorithm.sort *module* or to std.algorithm.package.sort *function* publicly imported from the std.algorithm.sort module? The function. A symbol that is not specified as the module name in import statement or in a module statement is always *not* a module. I think our one saving grace here is that when you want to import a specific symbol from a module, this is not the syntax: import std.stdio.writefln; So there is never any ambiguity as to whether you mean a module identifier or other symbol. Interesting. But isn't there an ambiguity when the symbol is not the last one in the chain? Consider: a.b.c.x Could be static member d of class c in module a.b, or module member d in module a.b.c. Stop reading all my posts except for the ones I just posted. I was completely wrong in what I thought the compiler couldn't do, because the spec is lacking. I currently think DIP16 is invalid/worksforme (public imports allows splitting a module into a package). All that is left is how we could specifically import a package with one import statement. DIP15 covers that. But I don't even think we need that, we can fix Phobos without any compiler changes. -Steve
Re: DIP16: Transparently substitute module with package
Le 05/04/2012 16:35, Andrei Alexandrescu a écrit : On 4/4/12 10:53 AM, Steven Schveighoffer wrote: On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin michel.for...@michelf.com wrote: Question 2: does std.algorithm.sort refer to the std.algorithm.sort *module* or to std.algorithm.package.sort *function* publicly imported from the std.algorithm.sort module? The function. A symbol that is not specified as the module name in import statement or in a module statement is always *not* a module. I think our one saving grace here is that when you want to import a specific symbol from a module, this is not the syntax: import std.stdio.writefln; So there is never any ambiguity as to whether you mean a module identifier or other symbol. Interesting. But isn't there an ambiguity when the symbol is not the last one in the chain? Consider: a.b.c.x Could be static member d of class c in module a.b, or module member d in module a.b.c. Andrei The whole point of this thread is to import symbols from submodules into a module. Obviously, this tends to create collisions. This one is hard to solve and should probably be an error. However, such a collision will also appear with DIP16, and DIP16 cause also other type of collisions. So that one is superior - even if not perfect
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 10:33:14 -0400, Michel Fortin michel.for...@michelf.com wrote: On 2012-04-05 11:46:38 +, Steven Schveighoffer schvei...@yahoo.com said: I don't like this proposal, simply because this means one function/symbo l per submodule. It should be more flexible than that. But I like the li ne of thinking. I have the same reserve about it's lack of flexibility too. It would be a nice thing to have for all those libraries having one module per class as it'd reduce the length of the fully qualified name you have to use when you need to disambiguate. I see the point you are going for. I don't really like the one-class-per-module style as much as how phobos has one module per category. But that's not an excuse not to examine this possibility. I think it's a different issue than what DIP16/DIP15 is trying to solve. But for moving a module like std.algorithm to a package, it's cumbersome. Not really. Just move the files to another directory (i.e. std/internal/algorithm) and publicly import them. Let's re-examine the issue. We need to allow splitting of a module X.d into pieces for maintenance (or possibly accessibility -- disallowing friends). But we don't want to break code which currently uses FQN to access X's symbols. I think the following might work: algorithm.d: import this = std.algorithm_impl.sort; Which then imports std.algorithm_impl.sort, and effectively aliases all its symbols into algorithm.d. If std.algorithm_impl.sort defines a function called sort, then it's also aliased to std.algorithm.sort. In essence, sort has *two* FQN, but there are no FQN that refer to more tha n one symbol. This is what a public import should do. I wasn't aware of this. Mostly because the spec omits that feature. I have to retract almost everything I've argued, because we already have the means to fix what I think DIP16 is trying to solve without any compiler changes. -Steve
Re: Custom attributes (again)
On Thursday, 5 April 2012 at 13:23:44 UTC, Manu wrote: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Wow, August 2009. Interesting that it tends to be so controversial in that case :) DIP 6 sucks. It has been fully implemented for some time, but it was written to be useless: Also at this first stage, a user cannot define new annotations. A user cannot inspect annotations. It gets worse: Annotations will allow several things: reduce the amount of keywords and extend the language more easily. [...] The language can be extended more easily just by adding new annotation names instead of new keywords: new keywords might render old code not compilable, while with new annotations that can never happen. [...] Annotations could be used for several things now. This proposal has a few major flaws in the design: 1) it is useless. Doesn't include inspection. 2) The rationale was to reduce keywords, which opened the door for a strange old/new split. Is it pure or @pure? property or @property? The question is if it was introduced before or after DIP6 was implemented rather than anything else. 3) The idea of applying it to things now instead of a new concept led to a pretty lame implementation. It mentions being a step toward real annoations, but in practice, it was a step in the wrong direction.
Re: DIP16: Transparently substitute module with package
Le 05/04/2012 16:47, Steven Schveighoffer a écrit : But for moving a module like std.algorithm to a package, it's cumbersome. Not really. Just move the files to another directory (i.e. std/internal/algorithm) and publicly import them. std/internal isn't good. If I just want to import sort, I would have to do std.internal.algorithm.sort, which isn't good. Plus, the package accessibility modifier would be broken with such a pattern. The all.d, package.d, _.d, or, as I propose foldername.d (and submodules into foldername) do not break package accessibility modifier, which is better.
Re: Unicode, graphemes and D
FYI http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002# Maybe helpful for your GSOC project: as part of a larger code base, we have implemented many standard Unicode algorithms (normalization; casefolding; graphemes; info like general category, Bidi class, joining type, etc.; ...). The doc and source can be found at http://stephan.bitbucket.org/. As this was just a helper, it is not fully polished (but it works and is reasonably fast).
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix deadal...@gmail.com wrote: Le 05/04/2012 16:47, Steven Schveighoffer a écrit : But for moving a module like std.algorithm to a package, it's cumbersome. Not really. Just move the files to another directory (i.e. std/internal/algorithm) and publicly import them. std/internal isn't good. If I just want to import sort, I would have to do std.internal.algorithm.sort, which isn't good. import std.algorithm : sort; BTW, this doesn't work today, I'll file a bug. Plus, the package accessibility modifier would be broken with such a pattern. The all.d, package.d, _.d, or, as I propose foldername.d (and submodules into foldername) do not break package accessibility modifier, which is better. I don't really know what you mean, I didn't read that post. Would you mind posting a link or repeating that argument? -Steve
Slices and GC
Recently I've been working on some projects that involve parsing binary files. I've mainly been using std.file.read() to get the whole file as a huge array and then extracting slices. I had initially assumed that the GC would free any chunks of the array that didn't end up being referenced by these slices, but after reading some more, it looks like the whole array is kept in memory even if only a few elements are actually referenced. Is this actually the case? If so, might the language be extended to handle this situation?
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 10:59:31 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix deadal...@gmail.com wrote: Le 05/04/2012 16:47, Steven Schveighoffer a écrit : Not really. Just move the files to another directory (i.e. std/internal/algorithm) and publicly import them. std/internal isn't good. If I just want to import sort, I would have to do std.internal.algorithm.sort, which isn't good. import std.algorithm : sort; BTW, this doesn't work today, I'll file a bug. Nevermind, it works the same as if sort is defined in a std.algorithm module. I'm kind of surprised the FQN doesn't work though... -Steve
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 10:59:31 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix deadal...@gmail.com wrote: Plus, the package accessibility modifier would be broken with such a pattern. The all.d, package.d, _.d, or, as I propose foldername.d (and submodules into foldername) do not break package accessibility modifier, which is better. I don't really know what you mean, I didn't read that post. Would you mind posting a link or repeating that argument? Also, nevermind :) I realize what you are talking about now. This is a good point. Of course, there are other mechanisms to do this, and DIP15 already proposes an improvement for this. However, at least in the case of phobos, I don't think there's a lot of instances of package accessibility modifier. -Steve
Re: DIP16: Transparently substitute module with package
On 4/5/12 7:43 AM, Steven Schveighoffer wrote: I currently think DIP16 is invalid/worksforme (public imports allows splitting a module into a package). All that is left is how we could specifically import a package with one import statement. Not entirely (I was aware of the way public import works). An issue does exist - there are too many names, i.e. the alias pulled in the importing module and also the name being imported. This makes for odd synonyms such as std.algorithm_package.sort.sort being the same as std.algorithm.sort. The other issue is that obviously algorithm_package and algorithm must have distinct names, which makes the scheme a bit awkward at least until we define a compelling convention. I guess we can live with all that. Andrei
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 11:23:12 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/5/12 7:43 AM, Steven Schveighoffer wrote: I currently think DIP16 is invalid/worksforme (public imports allows splitting a module into a package). All that is left is how we could specifically import a package with one import statement. Not entirely (I was aware of the way public import works). An issue does exist - there are too many names, i.e. the alias pulled in the importing module and also the name being imported. This makes for odd synonyms such as std.algorithm_package.sort.sort being the same as std.algorithm.sort. Right, but if one only ever imports std.algorithm, who cares what the submodule FQNs are? AIUI, DIP16 also doesn't really reduce the number of names either. The other issue is that obviously algorithm_package and algorithm must have distinct names, which makes the scheme a bit awkward at least until we define a compelling convention. I guess we can live with all that. Agreed. I think Don mentioned std.math already does something, we may want to look at that model. A couple issues that still need consideration: 1. If std.algorithm the module becomes std.algorithm the package, what happens with ddoc? We probably *do* need a compiler solution to this. 2. deadalnix pointed out that if we come up with a scheme where the package module and its submodules are in the same directory, the package accessibility qualifier can be used (hey look, a use for the package keyword!). -Steve
Re: Slices and GC
On Thursday, 5 April 2012 at 15:00:04 UTC, BLM wrote: Recently I've been working on some projects that involve parsing binary files. I've mainly been using std.file.read() to get the whole file as a huge array and then extracting slices. I had initially assumed that the GC would free any chunks of the array that didn't end up being referenced by these slices, but after reading some more, it looks like the whole array is kept in memory even if only a few elements are actually referenced. Is this actually the case? If so, might the language be extended to handle this situation? The GC can't really know which parts of the array you're using. For example, your only reference to the array might be a pointer, and you might be traversing the array in either direction, only keeping count of the remaining bytes until the array boundary. Consider .dup-ing the slices you're going to need, or using std.mmfile to map the file into memory - in that case, the OS won't load the unnecessary parts of the file into memory in the first place.
Re: DIP16: Transparently substitute module with package
Le 05/04/2012 17:23, Andrei Alexandrescu a écrit : On 4/5/12 7:43 AM, Steven Schveighoffer wrote: I currently think DIP16 is invalid/worksforme (public imports allows splitting a module into a package). All that is left is how we could specifically import a package with one import statement. Not entirely (I was aware of the way public import works). An issue does exist - there are too many names, i.e. the alias pulled in the importing module and also the name being imported. This makes for odd synonyms such as std.algorithm_package.sort.sort being the same as std.algorithm.sort. The other issue is that obviously algorithm_package and algorithm must have distinct names, which makes the scheme a bit awkward at least until we define a compelling convention. I guess we can live with all that. Andrei The first one isn't a problem. It isn't too many names, it is 2 names, and it happen when explicitly told to do so. The second is.
Re: Spec
On 4/5/12, Steven Schveighoffer schvei...@yahoo.com wrote: I was completely wrong in what I thought the compiler couldn't do, because the spec is lacking. I think it's very sad that even an old-timer like Steven has been tricked by the spec. It doesn't leave much hope for the newbies who didn't get a copy of TDPL. Some text needs to be wrapped inside of $(D1) sections ASAP. Things like scope classes, scope variables, class allocators.. Also there's some outdated information, e.g. Nested structs cannot be used as fields or as the element type of an array. - Not true Multiple AliasThis are allowed.. - this should be allowed, but it's been on the website for *years* and it still doesn't exist. How are users supposed to react to a feature advertised as working? A to-be-implemented note should be added. For dynamic array and object parameters, which are passed by reference - AFAIK Dynamic arrays are passed by value. Member functions of nested classes and structs do not have access to the stack variables of the enclosing function, but do have access to the other symbols - Not true
Re: Unicode, graphemes and D
On 05.04.2012 18:56, stephan wrote: FYI http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dolsh/20002# Maybe helpful for your GSOC project: as part of a larger code base, we have implemented many standard Unicode algorithms (normalization; casefolding; graphemes; info like general category, Bidi class, joining type, etc.; ...). The doc and source can be found at http://stephan.bitbucket.org/. As this was just a helper, it is not fully polished (but it works and is reasonably fast). Nice. I'll add a link to my proposal. Though I can use it iff the license is Boost compatible. -- Dmitry Olshansky
Mascot for D
Hi All, I am just starting my D adventure, I chose D over Go ! I think it will kool to have some marketing behind D. A mascot Dragon will look good ? http://4.bp.blogspot.com/-0YqxfqC5Ero/TfCTFkcPHbI/CNY/UaKuBVRyOpw/s1600/Skeleton_Dragon_Knight_Tattoo.jpg What do you guys think ? -Adam
Re: Mascot for D
On Thursday, 5 April 2012 at 16:28:52 UTC, crudbug wrote: Hi All, I am just starting my D adventure, I chose D over Go ! I think it will kool to have some marketing behind D. A mascot Dragon will look good ? http://4.bp.blogspot.com/-0YqxfqC5Ero/TfCTFkcPHbI/CNY/UaKuBVRyOpw/s1600/Skeleton_Dragon_Knight_Tattoo.jpg What do you guys think ? -Adam Shh...you're going to hurt D Man's feelings: http://dlang.org/images/d3.gif LLVM already uses a dragon very similar to that. I don't really think D needs a mascot, personally. Regards, Brad Anderson
Re: Mascot for D
Le 05/04/2012 18:33, Brad Anderson a écrit : On Thursday, 5 April 2012 at 16:28:52 UTC, crudbug wrote: Hi All, I am just starting my D adventure, I chose D over Go ! I think it will kool to have some marketing behind D. A mascot Dragon will look good ? http://4.bp.blogspot.com/-0YqxfqC5Ero/TfCTFkcPHbI/CNY/UaKuBVRyOpw/s1600/Skeleton_Dragon_Knight_Tattoo.jpg What do you guys think ? -Adam Shh...you're going to hurt D Man's feelings: http://dlang.org/images/d3.gif LLVM already uses a dragon very similar to that. I don't really think D needs a mascot, personally. Regards, Brad Anderson D man is fun, but ugly. However, the dragoon is already used, and I think it is better to have a friendly mascot, this dragon look sharp and agile, but not very friendly :D BTW, having a nice mascot for D is something I definitively think is good.
Re: Slices and GC
On Thursday, 5 April 2012 at 15:30:45 UTC, Vladimir Panteleev wrote: The GC can't really know which parts of the array you're using. For example, your only reference to the array might be a pointer, and you might be traversing the array in either direction, only keeping count of the remaining bytes until the array boundary. Consider .dup-ing the slices you're going to need, or using std.mmfile to map the file into memory - in that case, the OS won't load the unnecessary parts of the file into memory in the first place. I had considered using .dup, but I wanted to minimize overhead. I should probably look into std.mmfile or pull the data out in smaller chunks that the GC can handle individually. If the GC can distinguish between pointers and slices, it should theoretically be able to prune an array that is only referenced by slices, but I'm not sure how well that would fit into the current GC system.
Re: Custom attributes (again)
On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.
Re: Custom attributes (again)
Le 05/04/2012 19:35, Walter Bright a écrit : On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution. They should be attached to declarations.
Re: Spec
On Thu, 05 Apr 2012 11:57:14 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 4/5/12, Steven Schveighoffer schvei...@yahoo.com wrote: I was completely wrong in what I thought the compiler couldn't do, because the spec is lacking. I think it's very sad that even an old-timer like Steven has been tricked by the spec. It doesn't leave much hope for the newbies who didn't get a copy of TDPL. Who are you calling old-timer? ;) I think this is a bit of an exaggeration. Most of the spec is correct. You can get pretty far without TDPL in D2. Some text needs to be wrapped inside of $(D1) sections ASAP. Things like scope classes, scope variables, class allocators.. Also there's some outdated information, e.g. Nested structs cannot be used as fields or as the element type of an array. - Not true Multiple AliasThis are allowed.. - this should be allowed, but it's been on the website for *years* and it still doesn't exist. How are users supposed to react to a feature advertised as working? A to-be-implemented note should be added. For dynamic array and object parameters, which are passed by reference - AFAIK Dynamic arrays are passed by value. Member functions of nested classes and structs do not have access to the stack variables of the enclosing function, but do have access to the other symbols - Not true I think you should put together a pull request for these, or at least file a bug. -Steve
Re: DMD asserts using delegate and type inference
On 4/5/2012 2:34 AM, Jacob Carlborg wrote: Done: http://d.puremagic.com/issues/show_bug.cgi?id=7827 Thank-you.
Re: DMD asserts using delegate and type inference
On 4/5/2012 2:30 AM, Jacob Carlborg wrote: Yeah, I know. I was hoping someone could help me finding a reduced test case. It's still best to submit them there. Several people often comb through the issues and help finding reduced cases.
Re: Spec
On 4/5/12, Steven Schveighoffer schvei...@yahoo.com wrote: Who are you calling old-timer? ;) Heheh, I meant that with respect! Respect the ol' wizards of D. :p I'll make a pull for those things later.
Re: Custom attributes (again)
On 4/5/12 12:44 PM, deadalnix wrote: Le 05/04/2012 19:35, Walter Bright a écrit : On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution. They should be attached to declarations. The question was whether the declaration affects the type of the declared or not. Andrei
Re: DIP16: Transparently substitute module with package
On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote: On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch wrote: On 04/05/2012 02:58 PM, Steven Schveighoffer wrote: No, public imports simply mean that you can view the publicly imported module. It does *not* add aliases to the importing module. Have you tried it? I just did. OK, what the hell are we arguing about then?! DIP16 is worksforme :) See this part of the spec: http://dlang.org/module.html Read the part on public modules. You may understand why I didn't know about that feature (which seems to work on all the installed compilers I have, back to 2.033). I just read the public import part of TDPL, and there it is, all spelled out quite nicely. I'm going to file a bug against the spec... grrr... I'm now firmly in the we don't need to change anything, just refactor the modules and use public import camp. We don't even need to change ANYTHING in the compiler! Forget everything I said before in this thread ;) I suppose the only thing we don't get is being able to have a module and a package with the same FQN. I don't see that being a major issue. What doesn't work is being able to turn a module into a package with the same name. Right now, we could create a std.alg package with sub-modules containing all of std.algorithm's functionality and change std.algorithm to pubicly import them all, but you can't turn std.algorithm itself into a package without breaking code. The package.d portion of the proposal makes it so that you can. Now, public import's current behavior is _almost_ enough to make the second part completely unnecessary. The only change that would be required would be to make it so that std.algorithm.x looks in std/algorithm/package.d if there's no std.algorithm.x module, because otherwise the public imports in package.d would be putting all of the symbols in std.algorithm.package, not std.algorithm (that, and package.d isn't legal at present). So, the whole point of this proposal - to seemlessly allow the transition of a module to a package in place - _does_ require a language/compiler change. But moving stuff from a module to a new package does work already. - Jonathan M Davis
Re: Custom attributes (again)
On Thu, 05 Apr 2012 14:05:49 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/5/12 12:44 PM, deadalnix wrote: Le 05/04/2012 19:35, Walter Bright a écrit : On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution. They should be attached to declarations. The question was whether the declaration affects the type of the declared or not. For user-defined attributes, no. This is metadata for the programmer/lib to decode. Obviously, compiler-defined attributes can. -Steve
rpm spec for rhel and fedora
Hey, I created a new rpm spec. I already test it on rhel6 32bit and 64bit and works well both. dmd.spec http://pastebin.com/VYtkVHZ0 make_src.sh http://pastebin.com/UCUacyn2 dmd-2.058.src.tar.gz are generate by make_src.sh with dmd.2.058.zip. other files (source1~3) you can found them at http://ftp.digitalmars.com/dmd-2.058-0.fedora.x86_64.rpm or http://www.ownrepos.org/dl/rhel/6/stable/SRPMS/dmd-2.058-1.el6.src.rpm You can modify and use them anywhere, enjoy it.
Re: DIP16: Transparently substitute module with package
On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote: A couple issues that still need consideration: 1. If std.algorithm the module becomes std.algorithm the package, what happens with ddoc? We probably *do* need a compiler solution to this. That's assuming that you insist on keeping all of the documentation in one file. That arguably defeats the purpose of splitting up the modules. If there isn't enough in the module to split the documentation, then why do you need to split the module? What _would_ be valuable and the package.d could provide is an overview of the package. The ddoc comment for the package.d module can become the documentation for the package as a whole. 2. deadalnix pointed out that if we come up with a scheme where the package module and its submodules are in the same directory, the package accessibility qualifier can be used (hey look, a use for the package keyword!). Yes. std.datetime will need that once it's split. Without that, much of it can't be split and/or code would have to be needlessly duplicated. - Jonathan M Davis
Re: Custom attributes (again)
On 04/05/2012 08:05 PM, Andrei Alexandrescu wrote: On 4/5/12 12:44 PM, deadalnix wrote: Le 05/04/2012 19:35, Walter Bright a écrit : On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution. They should be attached to declarations. The question was whether the declaration affects the type of the declared or not. Andrei Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same.
Re: Slices and GC
On Thursday, April 05, 2012 17:00:03 BLM wrote: Recently I've been working on some projects that involve parsing binary files. I've mainly been using std.file.read() to get the whole file as a huge array and then extracting slices. I had initially assumed that the GC would free any chunks of the array that didn't end up being referenced by these slices, but after reading some more, it looks like the whole array is kept in memory even if only a few elements are actually referenced. Is this actually the case? If so, might the language be extended to handle this situation? http://dlang.org/d-array-article.html - Jonathan M Davis
Re: Custom attributes (again)
On 4/5/2012 11:32 AM, Timon Gehr wrote: Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same. Having it perturb the type implies a huge swamp of how that affects the semantics. You've got overloading, name mangling, type inference, implicit conversions, covariance, etc. All I can say is I see no way that can work with user defined semantics.
Re: Nested functions should be exempt from sequential visibility rules
On 4/3/2012 2:56 AM, Don Clugston wrote: Difficult but doable, but I think you end up with a really funky rule. It's a morass of special cases. I agree with Don. And in the end, is a morass of complexity worth it to deal with one special case that is both unusual and has a reasonable workaround? I'd say no.
Re: Slices and GC
On 05.04.2012 20:35, BLM wrote: On Thursday, 5 April 2012 at 15:30:45 UTC, Vladimir Panteleev wrote: The GC can't really know which parts of the array you're using. For example, your only reference to the array might be a pointer, and you might be traversing the array in either direction, only keeping count of the remaining bytes until the array boundary. Consider .dup-ing the slices you're going to need, or using std.mmfile to map the file into memory - in that case, the OS won't load the unnecessary parts of the file into memory in the first place. I had considered using .dup, but I wanted to minimize overhead. I should probably look into std.mmfile or pull the data out in smaller chunks that the GC can handle individually. Another idea is to copy out interesting parts of the original chunk to a separate storage array. This array will contain your sliced-out data just packed more tightly. If you have a upper bound on % of useful bytes then you can get away without extra allocations. The tricky part is reallocating this storage array, as it will make slices that point to it dangling (and keeping GC from deallocation), a workaround would be to use pure index-based slices that work on this block only. If the GC can distinguish between pointers and slices, it should theoretically be able to prune an array that is only referenced by slices, but I'm not sure how well that would fit into the current GC system. -- Dmitry Olshansky
Re: Nested functions should be exempt from sequential visibility rules
On 4/4/2012 12:57 AM, Don Clugston wrote: The most flexible method is to declare a local, nested struct. Any member functions (and variables!) of that struct have non-sequential semantics, so they can forward reference each other just fine. Thanks, Don. I didn't think of this, and it's an awesome solution. Can you put it in the D FAQ?
Re: Custom attributes (again)
Le 05/04/2012 20:51, Walter Bright a écrit : On 4/5/2012 11:32 AM, Timon Gehr wrote: Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same. Having it perturb the type implies a huge swamp of how that affects the semantics. You've got overloading, name mangling, type inference, implicit conversions, covariance, etc. All I can say is I see no way that can work with user defined semantics. I did some hacking into dmd in that regard, and I can confirm this is pretty hard. The problem is already quite hard, but the lack of separation of concerns into dmd's ast make things even harder. I'm afraid we have to delay anything that do codeception in a first shot, which is really sad because this is promising. I still think this is somewhere we have to go at some point, but we will have to wait.
benchmark dict list and string, D vs python vs lua
Hey, I wrote some code to benchmark dict list and string in D, python and lua. D is a great language, but some library look comparatively slow. Some where may be wrong, I start D just today. D test: code: http://pastebin.com/qF7N4wLx dict set: 2.251s dict get: 1.957s dict cleat: 0.00s list set: 0.085s list get: 0.007s list each: 0.014s str find: 1.254s str replace: 1.870s Python test: code: http://pastebin.com/m3qMjPcM dict set: 1.05s dict get: 0.75s dict cleat: 0.11s list set: 0.02s list get: 0.09s list each: 0.09s str find: 0.94s str replace: 0.67s Lua test: code: http://pastebin.com/TFTnsWzX dict set: 2.11s dict get: 0.87s dict cleat: 0.19s list set: 0.33s list get: 0.03s list each: 0.09s str find: 0.94s str replace: 1.10s Compare ( mean faster than): dict set: python lua D dict get: python lua D dict clear: D lua python list set: python D lua list get: D lua python list each: D lua = python str find: python = lua D str replace: python lua D C algorithm (with -O3): map tree set: 0.70s map tree get: 0.39s map tree clear: 0.23 chain set: 0.09s chain get: too large ... chain each: 0.05s variable length list set: 0.025s variable length list get: 0.01s variable length list each: 0.01s quick search find: 0.29s remalloc replace: 0.40s chain replace: 0.40s I think the one of problems is to!string(int) too slow, snprintf will better.
Re: Unicode, graphemes and D
On Thursday, 5 April 2012 at 16:17:46 UTC, Dmitry Olshansky wrote: Though I can use it iff the license is Boost compatible. Ah, the licensing question. I am not a lawyer and I don't know much about copyright law. So you have to do your own research. But here is my view regarding the unicodedata.d license situation. Our code is Boost licensed. It is however not a clean-room installation. Although almost all algorithms and data structures are different and there is minimal (and clearly marked) direct copying, we have looked quite a bit at the ICU implementation (and its predecessors) for inspiration. The ICU license is very permissive, hence you should be ok here. Furthermore, data files from the Unicode Consortium are part of the distribution. They are used in the script mode (version SCRIPT_DATA) to generate the relevant Unicode data in an appropriate format. Furthermore, they are used in the extensive unit tests (version ALL_UNIT_TESTS) for testing correctness against various test files and derived property files. Again, the data files have a very permissive license. Let me know if I can be of any help.
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote: A couple issues that still need consideration: 1. If std.algorithm the module becomes std.algorithm the package, what happens with ddoc? We probably *do* need a compiler solution to this. That's assuming that you insist on keeping all of the documentation in one file. That arguably defeats the purpose of splitting up the modules. If there isn't enough in the module to split the documentation, then why do you need to split the module? I thought the whole point was code maintenance? Not documentation splitting... I would have expected people to continue to treat std.algorithm like it was one module, even though it imports several sub-modules for its implementation. What _would_ be valuable and the package.d could provide is an overview of the package. The ddoc comment for the package.d module can become the documentation for the package as a whole. 2. deadalnix pointed out that if we come up with a scheme where the package module and its submodules are in the same directory, the package accessibility qualifier can be used (hey look, a use for the package keyword!). Yes. std.datetime will need that once it's split. Without that, much of it can't be split and/or code would have to be needlessly duplicated. Hm.. I just thought of something, as long as the main package module imports everything from the same directory, and doesn't define anything, this isn't an issue. -Steve
Re: benchmark dict list and string, D vs python vs lua
On 4/5/12, lzzll ownre...@gmail.com wrote:
I think the one of problems is to!string(int) too slow, snprintf
will better.
Tables to the rescue:
__gshared string[int] table;
shared static this()
{
foreach (i; 0 .. MAX_RANGE)
table[i] = to!string(i);
}
Then use table[i] instead of to!string(i). Here's a comparison:
to!string:
test_dict -
test dict set (100)... 1.281s
test dict get (100)... 1.047s
test dict clear (100)...0.000s
test_list -
test list set (100)... 0.125s
test list get (100)... 0.000s
test list each (100)... 0.000s
test_str -
test str find (100)... 0.703s
test str replace (100)... 1.016s
table (http://pastebin.com/43Z4EwMj)
test dict set (100)... 0.891s
test dict get (100)... 0.109s
test dict clear (100)...0.000s
test_list -
test list set (100)... 0.078s
test list get (100)... 0.000s
test list each (100)... 0.000s
test_str -
test str find (100)... 0.125s
test str replace (100)... 1.203s
But it seems the str replace test got slower even though all the other
tests got faster.
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 14:24:10 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote: On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch I suppose the only thing we don't get is being able to have a module and a package with the same FQN. I don't see that being a major issue. What doesn't work is being able to turn a module into a package with the same name. Right now, we could create a std.alg package with sub-modules containing all of std.algorithm's functionality and change std.algorithm to pubicly import them all, but you can't turn std.algorithm itself into a package without breaking code. But so what? nobody has any code like: import std.algorithm.sort; So who cares where that module goes? I agree it would be ideal to put it there, but I don't think it's strictly necessary. And there is no need for the shortcut for fully qualified names. So, the whole point of this proposal - to seemlessly allow the transition of a module to a package in place - _does_ require a language/compiler change. I don't see how. Just move the code into another module and publicly import that module from std/algorithm.d. Problem pretty much solved. BTW, importing a directory was already proposed in DIP15. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15 -Steve
Re: Custom attributes (again)
On 2012-04-05 14:00, Manu wrote: I just want to add more real-world experience to the controversy. I'm finding myself needing to use custom attributes almost every day. I have numerous systems that need to scan the module for things marked accordingly to automate bindings to their respective systems. Yes, give us custom attributes now :) -- /Jacob Carlborg
Re: benchmark dict list and string, D vs python vs lua
On 4/5/12 2:00 PM, lzzll wrote: Hey, I wrote some code to benchmark dict list and string in D, python and lua. D is a great language, but some library look comparatively slow. Some where may be wrong, I start D just today. [snip] Thanks for the benchmark, good comparisons are always helpful. I think the one of problems is to!string(int) too slow, snprintf will better. You're right. In fact I took a minute to adapt some C++ code I wrote for work into a faster to!string routine. On my machine I get: $ ./test.py test_dict - test dict set (100)... 0.64s test dict get (100)... 0.40s test dict clear (100)...0.09s test_list - test list set (100)... 0.02s test list get (100)... 0.08s test list each (100)... 0.06s test_str - test str find (100)... 0.47s test str replace (100)... 0.48s $ ./test test_dict - test dict set (100)... 0.729s test dict get (100)... 0.261s test dict clear (100)...0.000s test_list - test list set (100)... 0.073s test list get (100)... 0.001s test list each (100)... 0.001s test_str - test str find (100)... 0.593s test str replace (100)... 0.804s Not too shoddy! I'll work on adding the better conversion routine to Phobos. Andrei
Re: Spec
On 2012-04-05 17:57, Andrej Mitrovic wrote: On 4/5/12, Steven Schveighofferschvei...@yahoo.com wrote: I was completely wrong in what I thought the compiler couldn't do, because the spec is lacking. I think it's very sad that even an old-timer like Steven has been tricked by the spec. It doesn't leave much hope for the newbies who didn't get a copy of TDPL. Some text needs to be wrapped inside of $(D1) sections ASAP. Things like scope classes, scope variables, class allocators.. Also there's some outdated information, e.g. Nested structs cannot be used as fields or as the element type of an array.- Not true Multiple AliasThis are allowed..- this should be allowed, but it's been on the website for *years* and it still doesn't exist. How are users supposed to react to a feature advertised as working? A to-be-implemented note should be added. For dynamic array and object parameters, which are passed by reference- AFAIK Dynamic arrays are passed by value. Member functions of nested classes and structs do not have access to the stack variables of the enclosing function, but do have access to the other symbols- Not true This has been a problem for ages. There isn't a real specification. And the arrival of TDPL didn't make things better (in this case). -- /Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-05 19:35, Walter Bright wrote:
On 4/5/2012 5:00 AM, Manu wrote:
C# and Java both have attributes, following these established design
patterns, I
don't think there should be any mystery over how they should be
implemented.
At the Lang.NEXT conference over the last 3 days, I was able to talk to
many smart people about attributes. But I did find some confusion - are
they best attached to the variable/function (i.e. storage class), or
attached to the type (type constructor)? I think the former. Attaching
it to the type leads to all sorts of semantic issues.
From your list of uses, it looks like attaching it to the variable or
function is an apropos solution.
If I recall correctly, both Java annotations and C# attributes let you
specify with a fine grained control on what the attributes are attached to.
@foo FooBar bar () {}
For example, is @foo attached to FooBar or bar. Java uses the
@Target annotation to specify this.
--
/Jacob Carlborg
D projects list
I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of I didn't now about you project see, e.g. Modern COM Programming in D thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note Planned tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Custom attributes (again)
On 05-04-2012 22:06, Jacob Carlborg wrote:
On 2012-04-05 19:35, Walter Bright wrote:
On 4/5/2012 5:00 AM, Manu wrote:
C# and Java both have attributes, following these established design
patterns, I
don't think there should be any mystery over how they should be
implemented.
At the Lang.NEXT conference over the last 3 days, I was able to talk to
many smart people about attributes. But I did find some confusion - are
they best attached to the variable/function (i.e. storage class), or
attached to the type (type constructor)? I think the former. Attaching
it to the type leads to all sorts of semantic issues.
From your list of uses, it looks like attaching it to the variable or
function is an apropos solution.
If I recall correctly, both Java annotations and C# attributes let you
specify with a fine grained control on what the attributes are attached to.
@foo FooBar bar () {}
For example, is @foo attached to FooBar or bar. Java uses the
@Target annotation to specify this.
C#'s grammar directly encodes what metadata element the attribute is
attached to. How feasible this is with D's rather... loose
attribute/modifier parsing, I don't know.
--
- Alex
Re: Mascot for D
deadalnix wrote: Le 05/04/2012 18:33, Brad Anderson a écrit : On Thursday, 5 April 2012 at 16:28:52 UTC, crudbug wrote: Hi All, I am just starting my D adventure, I chose D over Go ! I think it will kool to have some marketing behind D. A mascot Dragon will look good ? http://4.bp.blogspot.com/-0YqxfqC5Ero/TfCTFkcPHbI/CNY/UaKuBVRyOpw/s1600/Skeleton_Dragon_Knight_Tattoo.jpg What do you guys think ? -Adam Shh...you're going to hurt D Man's feelings: http://dlang.org/images/d3.gif LLVM already uses a dragon very similar to that. I don't really think D needs a mascot, personally. Regards, Brad Anderson D man is fun, but ugly. However, the dragoon is already used, and I think it is better to have a friendly mascot, this dragon look sharp and agile, but not very friendly :D BTW, having a nice mascot for D is something I definitively think is good. How about a (digital) martian? :)
Re: Mascot for D
On Apr 5, 2012 4:24 PM, Zbigniew Radosz zbig...@o2.pl wrote How about a (digital) martian? :) Lol it took me a second to get it. Great one :)
Re: Mascot for D
Honestly I think having a planet and its moons for »mascots« is amazing enough!
Re: D projects list
Denis V. Shelomovskij I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. Looks very cool, nice job! On 4/5/12, Denis Shelomovskij verylonglogin@gmail.com wrote: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned A newer binding of Tk is on github although dated 2008 (not mine): https://github.com/lysevi/dkinter I've got an updated version that can use the newer Tk that has ttk (more native-look widgets). But I didn't bother with Tk much because it basically comes down to having to pass strings to a Tk eval function. For anything complicated you have to allocate a ton of strings.. Tk is probably best left for use with scripting languages imo.
Re: Mascot for D
On 4/5/12 1:24 PM, Zbigniew Radosz wrote: How about a (digital) martian? :) You mean this guy? http://www.disney.co.uk/john-carter/characters/tars-tarkas.html
Re: DIP16: Transparently substitute module with package
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote: On Thu, 05 Apr 2012 14:24:10 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote: On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch I suppose the only thing we don't get is being able to have a module and a package with the same FQN. I don't see that being a major issue. What doesn't work is being able to turn a module into a package with the same name. Right now, we could create a std.alg package with sub-modules containing all of std.algorithm's functionality and change std.algorithm to pubicly import them all, but you can't turn std.algorithm itself into a package without breaking code. But so what? nobody has any code like: import std.algorithm.sort; So who cares where that module goes? I agree it would be ideal to put it there, but I don't think it's strictly necessary. And there is no need for the shortcut for fully qualified names. So, the whole point of this proposal - to seemlessly allow the transition of a module to a package in place - _does_ require a language/compiler change. I don't see how. Just move the code into another module and publicly import that module from std/algorithm.d. Problem pretty much solved. The issue is code organization. If you want to split up std.algorithm (or std.datetime or whatever) into multiple modules, you have to create a new package with a completely different name with no connection to the original save for the fact that the original publicly imports it. For instance, with the work that I've done thus far on splitting std.datetime, I've had to create a std.dtime package to hold the modules and have std.datetime pubicly import them. This automatically creates the issue of what the difference between them is (for anyone new to Phobos) and does not indicate their relation at all in the hierarchy. It would be much cleaner to be able to turn std/datetime.d into std/datetime/ with a package.d in it along with the new modules. No, we don't _have_ to do something to make it so that std.algorithm can be turned into std/algorithm/ while still not breaking code. But it would be very nice. Certainly, I don't understand why this DIP would ever have been proposed if Andrei didn't find it valuable. BTW, importing a directory was already proposed in DIP15. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15 Yes, but having a package.d with the public imports gives you much finer- grained control over what gets imported, and DIP15 doesn't solve the problem of fully qualified uses of std.alorgithm.sort not breaking when std.algorithm.sort gets moved to something like std.algorithm.sorting.d. So, DIP15 doesn't work as a means of seemlessly breaking up a module. It just _mostly_ works as one (since people usually don't fully qualify symbols). Also, package.d would give us a means for documenting a package, which I would very much like to be able to do. Having std.datetime give an overview of the std.dtime package is definitely worse than having a means of having the package document itself - which the package.d file should be able to give us. The package.d portion of DIP16 allows a means of controlling what importing a package would mean, it provides a means of turning a module into package in place, and it potentially provides a way of documenting a package - all of which are valuable. Whether they're valuable enough to merit a language change is obviously up for debate, but certainly, as the designer and primary maintainer of one of the main targets for being split up, I very much like the idea of being able to split up a module in place rather than having to create a new package with a new name with no obvious relation to the original. - Jonathan M Davis
Re: DIP16: Transparently substitute module with package
On Thursday, April 05, 2012 15:26:14 Steven Schveighoffer wrote: On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote: A couple issues that still need consideration: 1. If std.algorithm the module becomes std.algorithm the package, what happens with ddoc? We probably *do* need a compiler solution to this. That's assuming that you insist on keeping all of the documentation in one file. That arguably defeats the purpose of splitting up the modules. If there isn't enough in the module to split the documentation, then why do you need to split the module? I thought the whole point was code maintenance? Not documentation splitting... I would have expected people to continue to treat std.algorithm like it was one module, even though it imports several sub-modules for its implementation. If the module isn't large enough to be split for documentation, I find it hard to believe that it needs to be split for maintenance. And if all you care about is sub-modules for implementation and want all of the functions in the same module still, then this DIP is pointless. All you have to do is declare undocumented sub-modules which hold the various implementations and have the actual module call them. We already do this sort of thing in Phobos to get around static destructors screaming about circular dependencies. I only see the need to split of a module as the DIP suggests when it's too big, and if the documentation isn't large enough to be an issue, then I don't see how the module itself is going to be too large unless it has a ton of helper stuff, and that stuff can be seemlessy put in another, undocumented module without needing to create a package. - Jonathan M Davis
Re: D projects list
Denis Shelomovskij verylonglogin@gmail.com wrote in message news:jlkubn$k4f$1...@digitalmars.com... I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of I didn't now about you project see, e.g. Modern COM Programming in D thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note Planned tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. There are already a List of D projects pages on the wiki: See the Projects section in the left nav panel here: http://prowiki.org/wiki4d/wiki.cgi I'm sure new categories could be added as needed. However, I do like the idea have having something that's searchable/sortable as you suggest. I would suggest though, that it be separated into two main parts: 1. Some sort of central database with a documented, publically-accessible machine interface, not a human interface. (And for the love of god, not XML.) 2. A human-usable frontend. That way, alternative frontends can be created. We could even create a D module (maybe in phobos?) to access the list. (IMO, that's how most web apps should work. And then backends that deal with the same type of data should use standardized interfaces. Hell, that's how *real* apps already work (standard file formats, network protocols, etc) - that's how computing finally achieved interoperability decades ago, before web apps sunk us back into the no interoperability dark ages again...But now I'm ranting, I'll stop.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend I want to write access to X resource, or everything (whatever) and the backend would send back a captcha image. The front end would then show it to the user, and relay the answer back to the backend. Actually, better yet, the backend would be user accounts only, but then there'd be a special account for anonymous captcha users. It's be one anon captcha user account for *each* frontend that wanted to allow captcha. The frontend would then use whatever the hell captcha system it wanted and, if the user succeeds, the frontend would transparently communicate with the backend via its own anon captcha user account. And if the captcha system used by the frontend turns out to suck, or be bypassable, or isn't even being used by the frontend, then the backend could disable or revoke that frontend's anon captcha user account. The backend could still, optionally, provide its own official captcha system to any frontends that wanted to use it.
Re: D projects list
On Thursday, 5 April 2012 at 21:02:15 UTC, Nick Sabalausky wrote: I would suggest though, that it be separated into two main parts: kill both birds with one web.d.
Re: D projects list
On Apr 5, 2012 5:04 PM, Nick Sabalausky a@a.a wrote I would suggest though, that it be separated into two main parts: 1. Some sort of central database with a documented, publically-accessible machine interface, not a human interface. (And for the love of god, not XML.) 2. A human-usable frontend. That way, alternative frontends can be created. We could even create a D module (maybe in phobos?) to access the list. (IMO, that's how most web apps should work. And then backends that deal with the same type of data should use standardized interfaces. Hell, that's how *real* apps already work (standard file formats, network protocols, etc) - that's how computing finally achieved interoperability decades ago, before web apps sunk us back into the no interoperability dark ages again...But now I'm ranting, I'll stop.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend I want to write access to X resource, or everything (whatever) and the backend would send back a captcha image. The front end would then show it to the user, and relay the answer back to the backend. Actually, better yet, the backend would be user accounts only, but then there'd be a special account for anonymous captcha users. It's be one anon captcha user account for *each* frontend that wanted to allow captcha. The frontend would then use whatever the hell captcha system it wanted and, if the user succeeds, the frontend would transparently communicate with the backend via its own anon captcha user account. And if the captcha system used by the frontend turns out to suck, or be bypassable, or isn't even being used by the frontend, then the backend could disable or revoke that frontend's anon captcha user account. The backend could still, optionally, provide its own official captcha system to any frontends that wanted to use it I for one, absolutely love the way you think. This is a great idea and the way it should be done. But, what is wrong with xml when used correctly.
