Re: dmd 2.063 beta 5
On Friday, 24 May 2013 at 13:54:21 UTC, Dicebot wrote: There is an option to prohibit initializers for struct member declarations at all and allow CTFE-able default constructors instead, but that would have been a major change. I don't see a reason why we couldn't have both ways (1. member initializers and 2. CTFE-able default constructor) for defining the init state of structs. Probably the sensible thing would be to make all member initializers illegal iff a default constructor has been defined for a struct. I'd be interested in seeing a proper feature request discussion about this in a dedicated forum or at bugzilla.
v1.0.0 of templ-d: An Embedded D Template Engine
Hello everyone,
A few of you might have remembered me posting a proof-of-concept
embedded D template engine a week or two ago. I'd like to
announce that a few weeks of development later, I've extracted
the core idea of that into a Dub-compatible library, called
templ-d.
The syntax that templ-d uses is identical to that of eRuby, so
any Ruby programmers will feel right at home with this. However,
delimiters can easily be changed if you so choose.
Templ-d parses templates at compile time, so there is zero
runtime overhead when rendering templates. An optional object or
struct can be passed into templ-d functions, to provide outside
context to the template.
An example of what the syntax looks like:
% foreach(i; 0..2) {
Index: %= i %
% }
will return the string:
Index: 0
Index: 1
Index: 2
Details about passing in additional contexts and
shorthand/longhand notation plus examples are available at:
https://github.com/dymk/templ-d
The dub package is located at:
http://registry.vibed.org/packages/templ-d
This is the first public-presentable D project I've done, so
critique on the code and pull requests are very welcome. On a
side note, a target I've got for the library is to be an
alternative template engine for vibe-d, a web framework written
in D, but I'll cross that bridge in the future.
Re: dmd 2.063 beta 5
On Monday, 27 May 2013 at 07:32:15 UTC, TommiT wrote: I don't see a reason why we couldn't have both ways (1. member initializers and 2. CTFE-able default constructor) for defining the init state of structs. Probably the sensible thing would be to make all member initializers illegal iff a default constructor has been defined for a struct. I'd be interested in seeing a proper feature request discussion about this in a dedicated forum or at bugzilla. Well, technically we can, of course, it won't be that different from current situation (even more confusing though). Consistency issue Don has convinced me about though is that can't be such thing as member initializer for non-static members, as there is nothing to initialize there. Initialization happens when variable is created and that is defined by combination of T.init, struct literal syntax and constructors. So, contrary to usual local variable use case, the very same member initializer syntax does not really initialize anything, it just changes T.init value. I don't feel it is important enough to actually change anything but worth remembering as language design nitpick.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On 5/24/2013 11:12 PM, Diggory wrote: On 64-bit windows there is also the GetWriteWatch function which lets you access the dirty flag in the page table = no page faults = super efficient concurrent generational GC. Just a shame it doesn't exist on 32-bit systems for some reason. There's all sorts of interesting stuff in 64 bit windows :) The user mode thread scheduler is pretty cool. On the flip side: 32 bit is in its twilight days, and I am reasonably confident the next game I work on will be the last one that even supports 32 bits. Then I can finally use all the new 64 bit goodies :) 32 bits will be reserved for phones and tablets (and even then tablets will probably be making the switch pretty soon-ish)
Re: dmd 2.063 beta 5
Dicebot, el 23 de May a las 16:42 me escribiste:
something I may have actually used in real code writing a low-level
networking library:
struct Packet
{
immutable etherType = 0x0800; // IPv4 by default;
// ...
this(bool IPv6)
{
if (!IPv6)
return; // fine with default, same as Packet.init
else
{
etherType = 0x86DD;
// ...
}
}
}
You can achieve the same with:
if (!IPv6)
etherType = 0x0800;
else
...
There is no need to double-initialize a immutable value. If you want to
make it more explicit, just use something like:
enum defaultEtherType = 0x0800;
if (!IPv6)
etherType = defaultEtherType;
else
...
I don't think that very rare use case, which is perfectly covered by
this workaround justifies the complexity added by this
double-initialization. Also code review becomes a nightmare, when I see
immutable something = 1; I can't assume something will be always 1,
I have to take a look at the whole code looking for constructors. That
SUCKS.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte
Re: dmd 2.063 beta 5
Andrei Alexandrescu, el 23 de May a las 12:57 me escribiste: On 5/23/13 9:12 AM, Don wrote: No, it's not, it's a fix plus a new misfeature. Don, you're wrong. The feature is sensible. The problem with it is that it changes semantics of existing code. Is not sensible for code review. For me the price to pay for a feature that add so little is too high. ROI ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Un paracaidista, que no deja de caer. Lo que me lleva hacia arriba, es lo que me tira hacia abajo.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
Vladimir Panteleev, el 24 de May a las 09:55 me escribiste: When the GC is run: - Use VirtualProtect to mark all mutable memory pages as read-only - Add a vectored exception handler to handle the access violation exception - Resume the GC thread I've tried writing a generational GC for D that used page protection for write barriers a while ago. IIRC, I ran into performance issues (the page faults were rather expensive). Yeah, using memory protection to do what fork does manually is a known approach, discussed even in the Garbage Collection book[1]. The good thing about fork is it's so much easier to implement, and the OS is already highly tuned to do this for you. That's why, even when it might be good to explore, is not a very tempting approach for me (but I have it in mind as an alternative way to fix the potential deadlock caused by glibc internal mutex). This approach does have the benefit that it will not cause pages that have been moved to swap to be pulled out in order to be scanned every time, though. [1] http://books.google.de/books/about/Garbage_Collection.html?id=UdtQMAAJredir_esc=y -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Se ha dicho tanto que las apariencias engañan Por supuesto que engañarán a quien sea tan vulgar como para creerlo
Re: dmd 2.063 beta 5
On Monday, 27 May 2013 at 17:08:19 UTC, Leandro Lucarella wrote: You can achieve the same with: if (!IPv6) etherType = 0x0800; else ... There is no need to double-initialize a immutable value. As I have already answered to Don it is all about T.init - only way to change it currently is to use initalizer syntax. It is hardly an issue with this use case - more like the general issue that such syntax was chosen for something that does not mean initialization.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote: On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote: I'd like to know if there is interest in a precise garbage collector. There is interest in it, and Rainer Schütze did a talk on it at DConf. At the current pace (assuming that Andrei actually posts one on Monday even though it's a federal holiday in the US), it'll be posted on June 3rd (and if he skips Monday, then it'll probably be June 5th). And actually, the precise GC changes stand a much better chance of making it into druntime in the short term than any concurrency changes do. - Jonathan M Davis That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a deal breaker for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon. -- Brian
Re: dmd 2.063 beta 5
Steven Schveighoffer, el 23 de May a las 23:53 me escribiste: On Thu, 23 May 2013 23:38:32 -0400, Walter Bright newshou...@digitalmars.com wrote: On 5/23/2013 7:38 PM, Steven Schveighoffer wrote: This is one change where ALL code broken by this change is fixable with a simple solution, and at some point, people will have to deal with this. Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning. If they aren't in the mood to change their code, they don't have to upgrade to the latest compiler. That's completely FALSE. You might need some bugfixes! That view of if you want to be up to date you have to be willing to update a lot of code is really hurting D's stability. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab
New std.uni Approved
With a vote 15/0 the new standard std.uni is approved to replace the existing module. Several people were in favor of the name changing to std.unicode others opposed unless it was part of a Phobos restructure. Such is up to the core devs to decide. Congrads Dmitry.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 27 May 2013 at 17:56:10 UTC, Brian Rogoff wrote: On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote: On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote: I'd like to know if there is interest in a precise garbage collector. There is interest in it, and Rainer Schütze did a talk on it at DConf. At the current pace (assuming that Andrei actually posts one on Monday even though it's a federal holiday in the US), it'll be posted on June 3rd (and if he skips Monday, then it'll probably be June 5th). And actually, the precise GC changes stand a much better chance of making it into druntime in the short term than any concurrency changes do. - Jonathan M Davis That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a deal breaker for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon. -- Brian It's actually possible to improve the precision of the GC without any additional type info. As long as you can give some unique ID to each type when you allocate it then the GC can learn the layout of that type on the fly. For example a simple algorithm would be: - When a new ID is first see create new type-info that is all pointers. - While scanning an instance of that type, if a pointer points to a value in the higher half, or a sufficiently low value which is not equal to zero, then remove this pointer from the type-info. You would have to disable this for unions, but for the rest it should work fine. Plus with more intelligent algorithms you can handle more cases. You could even save the type-info to a file and reuse it later to improve performance.
Re: [article] Language Design Deal Breakers
On Sun, 26 May 2013 17:38:21 -0700 Jonathan M Davis jmdavisp...@gmx.com wrote: On Sunday, May 26, 2013 11:46:53 Walter Bright wrote: Making non-nullable pointers is just plugging one hole in a cheese grater. LOL. That is highly quotable. As a person who very much enjoys a quality cheese, I find the practice of preventing null dereferences quite distasteful.
Re: [article] Language Design Deal Breakers
On Sun, 26 May 2013 13:03:49 +0200 Paulo Pinto pj...@progtools.org wrote: Well at least for Android, yes there is a proof. http://blog.bugsense.com/post/49924755479/bigdata-in-motion-building-a-real-time-android http://www.bugsense.com/live Just watch NullPointerExceptions fly by. Pet peeve #3,748: Light-grey text on a bright white background. Gotta cram as many of those backlight photons into my eyes, while focusing on under-contrasted text, as I can! Still though, very interesting.
Re: Why UTF-8/16 character encodings?
On Sunday, 26 May 2013 at 21:08:40 UTC, Marcin Mstowski wrote: On Sun, May 26, 2013 at 9:42 PM, Joakim joa...@airpost.net wrote: Also, one of the first pages talks about representations of floating point and integer numbers, which are outside the purview of the text encodings we're talking about. They are outside of scope of CDRA too. At least read picture description before making out of context assumptions. Which picture description did you have in mind? They all seem fairly generic. I do see now that one paragraph does say that CDRA only deals with graphical characters and that they were only talking about numbers earlier to introduce the topic of data representation. If you can show that it is materially similar to my single-byte encoding idea, it might be worth looking into. Spending ~15 min to read Introduction isn't worth your time, so why should i waste my time showing you anything ? You claimed that my encoding was reinventing the wheel, therefore the onus is on you to show which of the multiple encodings CDRA uses that I'm reinventing. I'm not interested in delving into the docs for some dead IBM format to prove _your_ point. More likely, you are just dead wrong and CDRA simply uses code pages, which are not the same as the single-byte encoding with a header idea that I've sketched in this thread.
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 01:29:12 UTC, H. S. Teoh wrote: On Sun, May 26, 2013 at 05:20:59PM -0700, Ali Çehreli wrote: On 05/26/2013 01:04 PM, Walter Bright wrote: Yeah, I did the 'Soccer' one. http://www.handheldmuseum.com/Mattel/Soccer.htm That's before my time. :) I have played with ones similar to this though: http://www.handheldmuseum.com/Nintendo/Octopus.htm [...] Whoa. This one brings back the memories! Was this the one where you had to evade the tentacles and get to the sunken ship and back? I must've been a primary schoolboy when I played this game (never owned it though -- I used to visit my grand-uncle's electronics store and played it there). T Oh man! My first handheld, http://www.gameandwatch.com/screen/widescreen/manhole/index.html
Re: [article] Language Design Deal Breakers
On Sunday, 26 May 2013 at 19:49:44 UTC, Nick Sabalausky wrote: On Sun, 26 May 2013 13:18:32 +0200 Paulo Pinto pj...@progtools.org wrote: Did you had the pleasure to write portable C or C++ code across multiple operating systems and vendors in the mid 90's? Luckily, no. For me it was just Win9x and DOS (using that awesome 32-bit extender DOOM and every other game of the time used, forget the name. DOS4GW?). And it was more mid-to-late 90's for me. (And then a little bit of PalmOS around 2000 or so.) Welcome to #ifdef spaghetti code and reluctance of using certain features due to inconsistent support. Back in 2000-2001 I was responsible for making a C codebase work across HP-UX, Solaris, Aix, Linux and Windows NT/2000, while using the OS vendors C compilers. Lots of fun with C standard compliance, this is where my #ifdef spaghetti code experience comes from. And the last time I really used C at work, before I moved definitely into C++/JVM/.NET land. When I left the company in 2003, they were starting the transition to .NET, by that time I was already writing C# code with C++/CLI bindings to the legacy stuff. -- Paulo
Re: [article] Language Design Deal Breakers
I really don't understand the reasoning for not removing as many known sources of bugs as is reasonably possible *provided* that doing so makes the situation incrementally better (rather than worse or to no effect). So will introducing non-nullable references make things worse or have no practical effect? There's also more to the equation than only reducing a potential source of bugs, as it also eliminates the manual null checks that programmers inevitably place in their code. More code always means introducing more bugs, along with higher development and maintenance costs. I also know that allowing null references has a use (I use them), but as was discussed before, we can have both options. Non-nullable references look like a win-win to me. --rt
Re: [article] Language Design Deal Breakers
On Monday, May 27, 2013 08:49:37 Rob T wrote: So will introducing non-nullable references make things worse or have no practical effect? We're going to add non-nullable references as a library type (NotNull!T or NonNullable!T or somesuch). That will allow you to type references as being non-nullable. It doesn't give quite as high a gain as having them being a built-in type, but there's a definite cost to adding something to the language (far higher than adding it to the library), and we don't think that the cost is worth it. Again, it's not the case that null references aren't a problem. It's just that they're being blown of proportion, and it's just not worth adding a built-in type to deal with them at this point (let alone making references in general non-nullable by default as some people would like done). You don't add new features to a language to solve every bug that comes along. We have a powerful language. Let's take advantage of it. The library solution should be fine. It just isn't as extreme a solution as some people would like. - Jonathan M Davis
Re: Skiping whitespace
On Sunday, 26 May 2013 at 23:32:36 UTC, Ali Çehreli wrote:
A single space character in the format specifier is a
placeholder for zero or more whitespace characters:
import std.stdio;
void main()
{
float x;
float y;
float z;
auto file = File(deneme.txt);
file.readf( %s %s %s, x, y, z);
}
Ali
Great ! Thanks a lot.
Re: [article] Language Design Deal Breakers
On Mon, 27 May 2013 08:22:02 +0200 Paulo Pinto pj...@progtools.org wrote: On Monday, 27 May 2013 at 01:29:12 UTC, H. S. Teoh wrote: On Sun, May 26, 2013 at 05:20:59PM -0700, Ali Çehreli wrote: On 05/26/2013 01:04 PM, Walter Bright wrote: Yeah, I did the 'Soccer' one. http://www.handheldmuseum.com/Mattel/Soccer.htm That's before my time. :) I have played with ones similar to this though: http://www.handheldmuseum.com/Nintendo/Octopus.htm [...] Whoa. This one brings back the memories! Was this the one where you had to evade the tentacles and get to the sunken ship and back? I must've been a primary schoolboy when I played this game (never owned it though -- I used to visit my grand-uncle's electronics store and played it there). T Oh man! My first handheld, http://www.gameandwatch.com/screen/widescreen/manhole/index.html These were my first: http://www.handheldmuseum.com/Tiger/Pinball.htm http://www.handheldmuseum.com/Tiger/ElectronicFootball.htm http://www.handheldmuseum.com/Tiger/DoubleDragon.htm http://www.handheldmuseum.com/Tiger/NinjaGaiden.htm (I like this thread, it makes me feel comparatively young ;) ) I played the heck out of those pinball and football ones. Strange though, I had totally forgotten about those two until browsing that site just now. I also had the Castlevania II, MegaMan 2, and some racing one from a different company, not sure who. No idea what happened to any of them. (The watch one I remember I lost a lng time ago.) Many years later I participated in a very fun little Make an LCD-handheld style game homebrew competition with a GBA entry (got third place): http://pdroms.de/files/gameboyadvance/my-robot-v1-0
Re: [article] Language Design Deal Breakers
On 5/26/2013 11:59 PM, Jonathan M Davis wrote: Again, it's not the case that null references aren't a problem. It's just that they're being blown of proportion, and it's just not worth adding a built-in type to deal with them at this point (let alone making references in general non-nullable by default as some people would like done). You don't add new features to a language to solve every bug that comes along. We have a powerful language. Let's take advantage of it. The library solution should be fine. It just isn't as extreme a solution as some people would like. Right. I just think the null pointer issue has become a cause celebre, reaching mythic proportions, culminating in that article that lists any language that allows null pointers is a deal-breaker.
Re: Out contracts: how to refer to objects' start state
On Sunday, 26 May 2013 at 01:47:39 UTC, Andrei Alexandrescu wrote:
On 5/25/13 9:18 PM, Adam D. Ruppe wrote:
On Sunday, 26 May 2013 at 01:12:35 UTC, Andrei Alexandrescu
wrote:
On 5/25/13 9:03 PM, Andrej Mitrovic wrote:
On 5/26/13, Andrei
Alexandrescuseewebsiteforem...@erdani.org
in { auto oldLen = this.length; }
out { assert(this.length == in.oldLen + 1); }
Since every in.xyz expression could access an arbitrary
method of the
old object,
Here, in.oldLen refers to the local variable you defined in
the in{}
scope, as opposed to plain oldLen which would be searing the
out{} scope.
Ohh, I see. Yes, that could work.
Thanks,
Andrei
Wouldn't it be simpler to define in the `in` clause what to pass
to the out clause? Something like:
class A {
void fun()
in { out oldLen = this.length; }
out { assert(this.length == oldLen + 1); }
body { ... }
}
Or even combine the two:
class A {
void fun()
in { out oldLen = this.length; }
out { assert(this.length == in.oldLen + 1); }
body { ... }
}
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 06:59:31 UTC, Jonathan M Davis wrote: On Monday, May 27, 2013 08:49:37 Rob T wrote: So will introducing non-nullable references make things worse or have no practical effect? We're going to add non-nullable references as a library type (NotNull!T or NonNullable!T or somesuch). That will allow you to type references as being non-nullable. It doesn't give quite as high a gain as having them being a built-in type, but there's a definite cost to adding something to the language (far higher than adding it to the library), and we don't think that the cost is worth it. What need to be added to the language to make the lib work is equivalent to what is needed to make it the default (Make the compiler track initialization), and is also required for other aspects of the language (initialize immutable objects). If I do agree that the cost in regard to code broken is high (and probably prohibitive) the cost in term of language complexity isn't what you claim it is. Additionally, safe behavior are either Nullable, with obligation to handle the null case from the user (which is easy to provide as a lib in D) or NonNullable. The default is the worst of both world, as it is nullable, without any obligation to handle that case and simply causing the program to crash (plus it will require runtime checks to make things @safe). Again, it's not the case that null references aren't a problem. It's just that they're being blown of proportion, and it's just not worth adding a built-in type to deal with them at this point (let alone making references in general non-nullable by default as some people would like done). You don't add new features to a language to solve every bug that comes along. We have a powerful language. Let's take advantage of it. The library solution should be fine. It just isn't as extreme a solution as some people would like. Many people here have expressed real problem with null, a lot of documentation on the web exists about it as well, and most modern languages try as hard as possible to get rid of it (even sometime in creative way as scala does as they can't get rid of it completely because of java compatibility).
Re: Out contracts: how to refer to objects' start state
On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote: That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible. Can you expand more on the breakage risk please ?
Re: Out contracts: how to refer to objects' start state
On Monday, May 27, 2013 09:37:38 deadalnix wrote: On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote: That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible. Can you expand more on the breakage risk please ? If nothing else, it would mean that the variables inside of the in block would not go out of scope when the in block ended, so their destructors would not be called and the like, whereas now they would be. The same goes for scope statements in the in block. I don't know how much of an issue any of that is realistically though. But Andrei may have other reasons why it would be a problem. - Jonathan M Davis
Re: [article] Language Design Deal Breakers
On Monday, May 27, 2013 09:27:58 deadalnix wrote: What need to be added to the language to make the lib work is equivalent to what is needed to make it the default (Make the compiler track initialization), and is also required for other aspects of the language (initialize immutable objects). I don't see why. NotNull would statically prevent assigning null to it (which is easy to do, since null has its own type) and will assert that any references assigned to it are null. You then have the guarantee that NotNull!T is never null. What would a built-in type do that that doesn't? The one point where null could get in - when constructed from a nullable reference - would have to be checked with a built-in type as well. The only way to prevent it is to make it illegal to assign a nullable reference to a non-nullable one and make it so that construction has to occur within the the non-nullable reference - e.g. NotNull!T(args). and most modern languages try as hard as possible to get rid of it Sure, some languages try and get rid of it, but for most part, major languages do not. If we were starting from scratch, then maybe it would be worth making non-nullable the default, but I completely concur with Walter that the issues with nullability are being blown way out of proportion. Sure, dereferencing null happens, but there are a ton of other bugs that are far more common. And with NotNull, you have a non-nullable reference. - Jonathan M Davis
Re: DMD under 64-bit Windows 7 HOWTO
On Sunday, 26 May 2013 at 23:33:56 UTC, Adam Wilson wrote: On Sun, 26 May 2013 16:22:54 -0700, Manu turkey...@gmail.com wrote: On 26 May 2013 15:03, Adam Wilson flybo...@gmail.com wrote: On Sat, 25 May 2013 18:24:41 -0700, Manu turkey...@gmail.com wrote: FYI. DMD did not work out-of-the-box on a vanilla VS2012/Win8 install. The Windows 8 SDK no longer includes the C++ compilers and VS2012 doesn't setup the Environment Variables used in sc.ini. Ah wow, sorry! I had no idea! I tent to lag 2-3 revisions behind the head of VS (finally using 2010) ;) They seem to make every version worse! Indeed. Some days I wonder if they actually care anymore. Well they really try hard to piss off developers. The last issue is the announcement that VS 2012 update 3 is the last one and developers will need to buy VS.Next for the remaining C++11 updates and the by side updates are actually not going to happen. http://blogs.msdn.com/b/bharry/archive/2013/05/08/some-thoughts-on-a-comment-about-vs-2012-3.aspx
Re: [article] Language Design Deal Breakers
On 5/27/2013 12:27 AM, deadalnix wrote: Many people here have expressed real problem with null, a lot of documentation on the web exists about it as well, and most modern languages try as hard as possible to get rid of it (even sometime in creative way as scala does as they can't get rid of it completely because of java compatibility). In D, right now (and especially with the beta) you can use the NotNull template. Yes, there are still a couple holes in it where a null initialization can slip through. But it catches the obvious cases, certainly well enough to demonstrate what value there is in non-null references, and you can use it now. I and I figure a lot of other people will be interested in the results you see. Meanwhile, we'll work to plug the remaining holes.
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 07:45:41 UTC, Jonathan M Davis wrote: I don't see why. NotNull would statically prevent assigning null to it (which is easy to do, since null has its own type) and will assert that any references assigned to it are null. You then have the guarantee that NotNull!T is never null. What would a built-in type do that that doesn't? The one point where null could get in - when constructed from a nullable reference - would have to be checked with a built-in type as well. The only way to prevent it is to make it illegal to assign a nullable reference to a non-nullable one and make it so that construction has to occur within the the non-nullable reference - e.g. NotNull!T(args). That is not enough. NotNull must be initialized, so the compiler have to track initialization in way it don't do today. This is the exact same processing required to ensure non null references.
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 07:53:05 UTC, Walter Bright wrote: On 5/27/2013 12:27 AM, deadalnix wrote: Many people here have expressed real problem with null, a lot of documentation on the web exists about it as well, and most modern languages try as hard as possible to get rid of it (even sometime in creative way as scala does as they can't get rid of it completely because of java compatibility). In D, right now (and especially with the beta) you can use the NotNull template. Yes, there are still a couple holes in it where a null initialization can slip through. But it catches the obvious cases, certainly well enough to demonstrate what value there is in non-null references, and you can use it now. Mostly NonNull is just like mostly @safe .
Re: [article] Language Design Deal Breakers
On Monday, May 27, 2013 09:59:32 deadalnix wrote: On Monday, 27 May 2013 at 07:45:41 UTC, Jonathan M Davis wrote: I don't see why. NotNull would statically prevent assigning null to it (which is easy to do, since null has its own type) and will assert that any references assigned to it are null. You then have the guarantee that NotNull!T is never null. What would a built-in type do that that doesn't? The one point where null could get in - when constructed from a nullable reference - would have to be checked with a built-in type as well. The only way to prevent it is to make it illegal to assign a nullable reference to a non-nullable one and make it so that construction has to occur within the the non-nullable reference - e.g. NotNull!T(args). That is not enough. NotNull must be initialized, so the compiler have to track initialization in way it don't do today. This is the exact same processing required to ensure non null references. @disable this(); would solve that. - Jonathan M Davis
Re: D's limited template specialization abilities compared to C++
On 5/27/13, Timon Gehr timon.g...@gmx.ch wrote: The reason is that the feature is undocumented. (The grammar specification mentions the syntax, though.) I wonder how many other easter eggs there are in the language. :p
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 08:06:48 UTC, Jonathan M Davis wrote: That is not enough. NotNull must be initialized, so the compiler have to track initialization in way it don't do today. This is the exact same processing required to ensure non null references. @disable this(); would solve that. That is the point, the logic required to support @disable this is the exact same that the one required to support non null. That is the freaking same thing : track initialization and yell at the programmer when you can't find it.
Re: Out contracts: how to refer to objects' start state
On Monday, 27 May 2013 at 07:42:44 UTC, Jonathan M Davis wrote: On Monday, May 27, 2013 09:37:38 deadalnix wrote: On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote: That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible. Can you expand more on the breakage risk please ? If nothing else, it would mean that the variables inside of the in block would not go out of scope when the in block ended, so their destructors would not be called and the like, whereas now they would be. The same goes for scope statements in the in block. I don't know how much of an issue any of that is realistically though. But Andrei may have other reasons why it would be a problem. You are right, destructor is an issue. The risk of name collision exists as well but I don't think it is realistically that widespread in actual codebase.
Re: [article] Language Design Deal Breakers
On 5/27/2013 2:05 AM, deadalnix wrote: On Monday, 27 May 2013 at 08:06:48 UTC, Jonathan M Davis wrote: That is not enough. NotNull must be initialized, so the compiler have to track initialization in way it don't do today. This is the exact same processing required to ensure non null references. @disable this(); would solve that. That is the point, the logic required to support @disable this is the exact same that the one required to support non null. That is the freaking same thing : track initialization and yell at the programmer when you can't find it. Are you arguing that notnull should be a core language feature instead of a library one?
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 09:08:16 UTC, Walter Bright wrote: On 5/27/2013 2:05 AM, deadalnix wrote: On Monday, 27 May 2013 at 08:06:48 UTC, Jonathan M Davis wrote: That is not enough. NotNull must be initialized, so the compiler have to track initialization in way it don't do today. This is the exact same processing required to ensure non null references. @disable this(); would solve that. That is the point, the logic required to support @disable this is the exact same that the one required to support non null. That is the freaking same thing : track initialization and yell at the programmer when you can't find it. Are you arguing that notnull should be a core language feature instead of a library one? I'm saying that NonNull require language support, either by making it a first class entity, or by introducing some other language feature like @disable this(). At the end it doesn't change anything for the compiler, the exact same work have to be done, simply on different entities. It can't be a 100% library feature as the work around @disable this shows. I think that ideally, nonnull pointer should be a core feature. Considering history, a library solution is preferable. But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler.
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 09:08:16 UTC, Walter Bright wrote: Are you arguing that notnull should be a core language feature instead of a library one? Can't day for deadalnix, but I'd argue it is much more useful as default behavior :P (does not matter, core or library, but we can't do defaults from library now) NonNullable!T in library is good, but if programmer can forget to handle null case, he will also forget to use proper library type. Best thing about restrictive-by-default approach is that you keep getting compile-time errors if you forget something. By the way same goes for impure-by-default, mutable-by-default etc. The very need for automatic attribute inference shows why such design approach is not that wise.
Re: [article] Language Design Deal Breakers
On Monday, May 27, 2013 11:17:57 deadalnix wrote: On Monday, 27 May 2013 at 09:08:16 UTC, Walter Bright wrote: On 5/27/2013 2:05 AM, deadalnix wrote: On Monday, 27 May 2013 at 08:06:48 UTC, Jonathan M Davis wrote: That is not enough. NotNull must be initialized, so the compiler have to track initialization in way it don't do today. This is the exact same processing required to ensure non null references. @disable this(); would solve that. That is the point, the logic required to support @disable this is the exact same that the one required to support non null. That is the freaking same thing : track initialization and yell at the programmer when you can't find it. Are you arguing that notnull should be a core language feature instead of a library one? I'm saying that NonNull require language support, either by making it a first class entity, or by introducing some other language feature like @disable this(). At the end it doesn't change anything for the compiler, the exact same work have to be done, simply on different entities. It can't be a 100% library feature as the work around @disable this shows. I think that ideally, nonnull pointer should be a core feature. Considering history, a library solution is preferable. But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler. Except that we already have that feature and have had it for some time. It's just that it has bugs which need to be sorted out (at least some of which were recently fixed). So, we don't need any features for NotNull to work that weren't going to have anyway. - Jonathan M Davis
Re: Tuples
On Monday, 27 May 2013 at 03:28:07 UTC, deadalnix wrote: On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote: On Monday, May 27, 2013 04:24:51 Diggory wrote: It also shouldn't break any code since the only addition to TypeTuple is a check to make sure that the undocumented behaviour of using it with non-types is disallowed, and in the case that this undocumented feature is used the code can simply switch to StaticTuple and be done. Well, changing TypeTuple to only accept types _will_ break code. It gets used quite heavily with foreach to get a static foreach, and that can involve using expressions instead of types. Anyone using TypeTuple heavily knows what it can do and will probably have used it for expressions at some point. It wouldn't surprise me in the least if it's already done in Phobos, and there's no way to know how much it is or isn't done elsewhere. Granted that nobody understand them, it is fair to say it should be changed. In case people agree: https://github.com/D-Programming-Language/phobos/pull/1309
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 09:27:28 UTC, Jonathan M Davis wrote: Except that we already have that feature and have had it for some time. It's just that it has bugs which need to be sorted out (at least some of which were recently fixed). So, we don't need any features for NotNull to work that weren't going to have anyway. We should really stop claiming we have features when we only wish we have them.
Re: Tuples
On Monday, 27 May 2013 at 09:25:14 UTC, Diggory wrote: Granted that nobody understand them, it is fair to say it should be changed. In case people agree: https://github.com/D-Programming-Language/phobos/pull/1309 I'm all for it. Thank you.
Re: Out contracts: how to refer to objects' start state
On Monday, 27 May 2013 at 09:06:58 UTC, deadalnix wrote: On Monday, 27 May 2013 at 07:42:44 UTC, Jonathan M Davis wrote: On Monday, May 27, 2013 09:37:38 deadalnix wrote: On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote: That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible. Can you expand more on the breakage risk please ? If nothing else, it would mean that the variables inside of the in block would not go out of scope when the in block ended, so their destructors would not be called and the like, whereas now they would be. The same goes for scope statements in the in block. I don't know how much of an issue any of that is realistically though. But Andrei may have other reasons why it would be a problem. You are right, destructor is an issue. The risk of name collision exists as well but I don't think it is realistically that widespread in actual codebase. Yet another reason why those variable should be declared as such in the `in` clause. Variables declared in the `in` clause using the `out` attribute would have their destruction done after the `out` clause, and all other variables declared in the `in` clause would be destructed after the `in` clause.
wc.d program from the website
Does the code at http://dlang.org/wc.html represent the canonical D code style? I note that: rdmd wc.d wc.d fails to behave analogously to how: /usr/bin/wc wc.d does. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: wc.d program from the website
On Monday, 27 May 2013 at 10:26:37 UTC, Russel Winder wrote: Does the code at http://dlang.org/wc.html represent the canonical D code style? I note that: rdmd wc.d wc.d fails to behave analogously to how: /usr/bin/wc wc.d does. I'm pretty sure canonical wc in D would use ranges now (spliter, byLine, walkLength). And yes, you are right about how it isn't very Unix-like with regards to how it handles the input.
Wondering about errors…
Using rdmd, it appears that the first error in the code can lead the parsing and template handling of everything following to be wrong. I keep finding that I am getting spurious errors about things nothing to do with the actual error, that simply go away when the real error is fixed. This would imply that most errors reported are generally spurious? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Discussion of TypeTuple naming
I gather this has been discussed before and even a potential solution submitted (https://github.com/D-Programming-Language/phobos/pull/780) However it was dismissed due to too much existing code being broken. I'd like to suggest a slightly less severe change which should still fix the issues with TypeTuple: https://github.com/D-Programming-Language/phobos/pull/1309 It introduces a new template, StaticTuple which can store any template parameters. The two templates are exactly equivalent except that TypeTuple checks that its parameters are actually types, so StaticTuple!(int, float) == TypeTuple!(int, float). Reasons for the change: - Tuples seem to confuse everyone trying to learn D, the inconsistency in TypeTuples is a big part of that. Naming the new type StaticTuple makes it abundantly clear that the built in Tuple type is for storing multiple values together at runtime while a StaticTuple is a similar construction but for compile time. It then follows directly that TypeTuple is a particular type of StaticTuple for dealing with types. - The current functionality of using TypeTuples with non-types is extremely useful and yet completely undocumented. This change means that if some code expects a StaticTuple we can be safe to assume that passing it non-types will be fine, and it also opens of the doors for other specialized versions of StaticTuple such as ExpressionTuple. I have avoided doing anything other than the most basic addition of StaticTuple in this pull request as further improvements are a separate issue that can be dealt with later. - Unless we plan to stick to the current absurd and confusing naming for TypeTuple forever, it's better to make the change sooner rather than later. Reasons why this change is not detrimental: - The result of the change is zero existing code actually failing to compile. TypeTuple will simply show a deprecation warning if used with non-types. - If even a deprecation warning is too much an arbitrarily large existing code-base can be fixed using a one off find and replace. - The new template is also still in the std.typetuple module. This is not ideal but it is also not a problem - it's common for a module to contain related types in addition to the one it's named after. - Any code that does use non-types with TypeTuple is using undocumented behaviour. Making undocumented behaviour deprecated is a very reasonable change even in the most stable of languages, so arguing that D is supposed to be stable and that this breaks too much is not a very convincing argument. - Almost all uses of TypeTuple are for dealing with types and so will be completely unaffected by the change. - There's no necessity to ever actually completely remove the deprecated behaviour, the deprecation warning is enough. It's not like code only has X amount of time to change its behaviour to the new system.
Re: Wondering about errors…
Yeah, me too.
I take a working program and add gf to the middle of it. Here's
the errors:
base.d(2143): Error: found '{' when expecting ';' following
statement
base.d(2168): Error: unexpected ( in declarator
base.d(2168): Error: basic type expected, not div
base.d(2168): Error: found 'div' when expecting ')'
base.d(2168): Error: no identifier for declarator
div.addChild(int)
base.d(2168): Error: semicolon expected following function
declaration
base.d(2168): Error: Declaration expected, not ','
base.d(2177): Error: Declaration expected, not 'if'
base.d(2179): Error: no identifier for declarator qrUrl
base.d(2180): Error: unrecognized declaration
OK now let's add a semicolon to it. Prepare yourself, here's
what dmd gives me now:
base.d(2141): Error: undefined identifier gf, did you mean
template to(T)?
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/format.d(1723):
Error: template std.format.formatRange does not match any
function template declaration. Candidates are:
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/format.d(1982):
std.format.formatRange(Writer, T, Char)(ref Writer w, ref T
val, ref FormatSpec!(Char) f) if (isInputRange!(T))
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/format.d(1723):
Error: template std.format.formatRange(Writer, T, Char)(ref
Writer w, ref T val, ref FormatSpec!(Char) f) if
(isInputRange!(T)) cannot deduce template function from argument
types !()(Appender!(string),immutable(wchar)[],FormatSpec!(char))
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(100):
Error: template instance
std.format.formatValue!(Appender!(string), immutable(wchar)[],
char) error instantiating
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(807):
instantiated from here: toStr!(string, immutable(wchar)[])
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(274):
instantiated from here: toImpl!(string, immutable(wchar)[])
arsd/characterencodings.d(75):instantiated from here:
to!(immutable(wchar)[])
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(807):
Error: template instance std.conv.toStr!(string,
immutable(wchar)[]) error instantiating
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(274):
instantiated from here: toImpl!(string, immutable(wchar)[])
arsd/characterencodings.d(75):instantiated from here:
to!(immutable(wchar)[])
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(274):
Error: template instance std.conv.toImpl!(string,
immutable(wchar)[]) error instantiating
arsd/characterencodings.d(75):instantiated from here:
to!(immutable(wchar)[])
arsd/characterencodings.d(75): Error: template instance
std.conv.to!(string).to!(immutable(wchar)[]) error instantiating
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(1718):
Error: template
std.array.Appender!(immutable(dchar)[]).Appender.put does not
match any function template declaration. Candidates are:
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2305):
std.array.Appender!(immutable(dchar)[]).Appender.put(U)(U
item) if (isImplicitlyConvertible!(U, T) || isSomeChar!(T)
isSomeChar!(U))
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2325):
std.array.Appender!(immutable(dchar)[]).Appender.put(Range)(Range
items) if (isInputRange!(Unqual!(Range)) !isInputRange!(Range))
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2334):
std.array.Appender!(immutable(dchar)[]).Appender.put(Range)(Range
items) if (isInputRange!(Range)
is(typeof(Appender.init.put(items.front
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2305):
Error: template
std.array.Appender!(immutable(dchar)[]).Appender.put cannot
deduce template function from argument types
!()(immutable(dchar)[])
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(1719):
Error: template
std.array.Appender!(immutable(dchar)[]).Appender.put does not
match any function template declaration. Candidates are:
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2305):
std.array.Appender!(immutable(dchar)[]).Appender.put(U)(U
item) if (isImplicitlyConvertible!(U, T) || isSomeChar!(T)
isSomeChar!(U))
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2325):
std.array.Appender!(immutable(dchar)[]).Appender.put(Range)(Range
items) if (isInputRange!(Unqual!(Range)) !isInputRange!(Range))
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2334):
std.array.Appender!(immutable(dchar)[]).Appender.put(Range)(Range
items) if (isInputRange!(Range)
is(typeof(Appender.init.put(items.front
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(2305):
Error: template
std.array.Appender!(immutable(dchar)[]).Appender.put cannot
deduce template function from argument types
!()(immutable(dchar)[])
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/array.d(1720):
Error: template std.array.replaceInto does not match any function
template
Re: Why UTF-8/16 character encodings?
On Monday, 27 May 2013 at 06:11:20 UTC, Joakim wrote: You claimed that my encoding was reinventing the wheel, therefore the onus is on you to show which of the multiple encodings CDRA uses that I'm reinventing. I'm not interested in delving into the docs for some dead IBM format to prove _your_ point. It's your idea and project. Showing that it is original / doing your research on previous efforts is probably something that *you* should do, whether or not it's someone else's point. More likely, you are just dead wrong and CDRA simply uses code pages Based on what?
Re: Discussion of TypeTuple naming
On 05/27/2013 01:36 PM, Diggory wrote:
I gather this has been discussed before and even a potential solution
submitted (https://github.com/D-Programming-Language/phobos/pull/780)
However it was dismissed due to too much existing code being broken.
I'd like to suggest a slightly less severe change which should still fix
the issues with TypeTuple:
https://github.com/D-Programming-Language/phobos/pull/1309
It introduces a new template, StaticTuple which can store any template
parameters. The two templates are exactly equivalent except that
TypeTuple checks that its parameters are actually types, so
StaticTuple!(int, float) == TypeTuple!(int, float).
Reasons for the change:
- Tuples seem to confuse everyone trying to learn D, the inconsistency
in TypeTuples is a big part of that. Naming the new type StaticTuple
makes it abundantly clear that the built in Tuple type is for storing
multiple values together at runtime while a StaticTuple is a similar
construction but for compile time.
It is not that similar, as it automatically expands into any context and
hence does not allow a nested structure.
It then follows directly that
TypeTuple is a particular type of StaticTuple for dealing with types.
I don't think that having a construct that is restricted to just types
makes a lot of sense.
- The current functionality of using TypeTuples with non-types is
extremely useful and yet completely undocumented. This change means that
if some code expects a StaticTuple we can be safe to assume that passing
it non-types will be fine, and it also opens of the doors for other
specialized versions of StaticTuple such as ExpressionTuple. I have
avoided doing anything other than the most basic addition of StaticTuple
in this pull request as further improvements are a separate issue that
can be dealt with later.
TypeTuple does not implement any functionality. It is an 'identity
function'.
- Unless we plan to stick to the current absurd and confusing naming for
TypeTuple forever, it's better to make the change sooner rather than later.
...
The new name should be an improvement. Certainly shorter.
I (and others) just use:
template Seq(T...){ alias Seq = T; }
As far as I am concerned, this won't change if the new name takes a
substantial amount more space.
Rust-based provocation :)
http://www.reddit.com/r/programming/comments/1f2nwe/zerors_rust_without_a_runtime/ It really makes me sad to see that Rust, despite being that immature and unstable is _already_ closer to embedded environments than D. Any possibility of a change? :P
Re: Are people using textmate for D programming?
On 2013-05-26 02:33, Andrei Alexandrescu wrote: Also, is it possible to switch to an alternative syntax inside D comments? I would guess so. At least it's possible in TextMate. You would probably need a specific character to indicate that the text that would follow should be parsed as a different language. -- /Jacob Carlborg
Re: Rust-based provocation :)
most minimal, few D features actually work: http://arsdnet.net/dcode/minimal.d slightly less minimal, with a few more things working: http://arsdnet.net/dcode/minimal.zip I haven't spent a lot of time on this, more just wondering if it could be done, so most of D still doesn't actually work but enough does for hello world (on linux here) at least. The example minimal.d program will spit out its own name and a newline when you run it, demonstrating command line args work, as well as a custom type.
Re: Out contracts: how to refer to objects' start state
On 5/27/13 3:21 AM, Idan Arye wrote:
Wouldn't it be simpler to define in the `in` clause what to pass to the
out clause? Something like:
class A {
void fun()
in { out oldLen = this.length; }
out { assert(this.length == oldLen + 1); }
body { ... }
}
Or even combine the two:
class A {
void fun()
in { out oldLen = this.length; }
out { assert(this.length == in.oldLen + 1); }
body { ... }
}
I think that got too cute.
Andrei
Re: Out contracts: how to refer to objects' start state
On 5/27/13 3:37 AM, deadalnix wrote: On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote: That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible. Can you expand more on the breakage risk please ? Easy - name collisions between the in and the out blocks. Andrei
Re: Out contracts: how to refer to objects' start state
On 5/27/13 3:42 AM, Jonathan M Davis wrote: On Monday, May 27, 2013 09:37:38 deadalnix wrote: On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote: That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible. Can you expand more on the breakage risk please ? If nothing else, it would mean that the variables inside of the in block would not go out of scope when the in block ended, so their destructors would not be called and the like, whereas now they would be. The same goes for scope statements in the in block. I don't know how much of an issue any of that is realistically though. But Andrei may have other reasons why it would be a problem. Oh, destructors too. Andrei
Re: Wondering about errors…
On Monday, 27 May 2013 at 11:51:45 UTC, Adam D. Ruppe wrote: Yeah, me too. base.d(2141): Error: undefined identifier gf, did you mean template to(T)? /home/me/d/dmd2/linux/bin32/../../src/phobos/std/format.d(1723): Error: template std.format.formatRange does not match any function template declaration. Candidates are: /home/me/d/dmd2/linux/bin32/../../src/phobos/std/format.d(1982): std.format.formatRange(Writer, T, Char)(ref Writer w, ref screens of errors make: *** [all] Error 1 C++ is the only language where error message can be bigger than the program. Unfortunately this happens sometimes in D too.
Re: [article] Language Design Deal Breakers
On 5/27/13 3:45 AM, Jonathan M Davis wrote:
On Monday, May 27, 2013 09:27:58 deadalnix wrote:
What need to be added to the language to make the lib work is
equivalent to what is needed to make it the default (Make the
compiler track initialization), and is also required for other
aspects of the language (initialize immutable objects).
I don't see why. NotNull would statically prevent assigning null to it (which
is easy to do, since null has its own type) and will assert that any
references assigned to it are null.
The problem is when NonNull is a member:
class A {
NonNull!A next;
this() {
if (condition) next = new A;
while (!another_condition) {
if (yet_another_condition) {
next = new A;
break;
}
}
}
}
Andrei
Re: [article] Language Design Deal Breakers
On 5/27/13 5:17 AM, deadalnix wrote: I'm saying that NonNull require language support, either by making it a first class entity, or by introducing some other language feature like @disable this(). At the end it doesn't change anything for the compiler, the exact same work have to be done, simply on different entities. It can't be a 100% library feature as the work around @disable this shows. The difference is that @disable this() and friends allows implementing NonNull PLUS a host of other restricted types, whereas plopping NonNull in the language just stops there. Big difference. I think that ideally, nonnull pointer should be a core feature. Considering history, a library solution is preferable. But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler. No. Andrei
Re: Why UTF-8/16 character encodings?
On Monday, 27 May 2013 at 12:25:06 UTC, John Colvin wrote: On Monday, 27 May 2013 at 06:11:20 UTC, Joakim wrote: You claimed that my encoding was reinventing the wheel, therefore the onus is on you to show which of the multiple encodings CDRA uses that I'm reinventing. I'm not interested in delving into the docs for some dead IBM format to prove _your_ point. It's your idea and project. Showing that it is original / doing your research on previous efforts is probably something that *you* should do, whether or not it's someone else's point. Sure, some research is necessary. However, software is littered with past projects that never really got started or bureaucratic efforts, like CDRA appears to be, that never went anywhere. I can hardly be expected to go rummaging through all these efforts in the hopes that what, someone else has already written the code? If you have a brain, you can look at the currently popular approaches, which CDRA isn't, and come up with something that makes more sense. I don't much care if my idea is original, I care that it is better. More likely, you are just dead wrong and CDRA simply uses code pages Based on what? Based on the fact that his link lists EBCDIC and several other antiquated code page encodings in its list of proposed encodings. If Marcin believes one of those is similar to my scheme, he should say which one, otherwise his entire line of argument is irrelevant. It's not up to me to prove _his_ point. Without having looked any of the encodings in detail, I'm fairly certain he's wrong. If he feels otherwise, he can pipe up with which one he had in mind. The fact that he hasn't speaks volumes.
Re: Rust-based provocation :)
On Monday, 27 May 2013 at 14:21:24 UTC, Adam D. Ruppe wrote: most minimal, few D features actually work: http://arsdnet.net/dcode/minimal.d slightly less minimal, with a few more things working: http://arsdnet.net/dcode/minimal.zip I haven't spent a lot of time on this, more just wondering if it could be done, so most of D still doesn't actually work but enough does for hello world (on linux here) at least. The example minimal.d program will spit out its own name and a newline when you run it, demonstrating command line args work, as well as a custom type. Ye, there is also https://bitbucket.org/timosi/minlibd , quite a mature attempt. But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable. Quoting one of reddit comments: You still have all the other language features, including unique pointers, generics, trait objects, stack/unique closures, etc. Currently possibility of D run-time tweaking is very limited by compiler expectations about its capabilities. Automatic memory allocation is widely known but emitting TypeInfo's for almost everything is as much painful.
Re: [article] Language Design Deal Breakers
On 5/27/13 5:38 AM, deadalnix wrote: On Monday, 27 May 2013 at 09:27:28 UTC, Jonathan M Davis wrote: Except that we already have that feature and have had it for some time. It's just that it has bugs which need to be sorted out (at least some of which were recently fixed). So, we don't need any features for NotNull to work that weren't going to have anyway. We should really stop claiming we have features when we only wish we have them. Let's say that this beta introduces an alpha-quality NonNull :o). Andrei
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 14:36:26 UTC, Andrei Alexandrescu wrote: On 5/27/13 5:17 AM, deadalnix wrote: I'm saying that NonNull require language support, either by making it a first class entity, or by introducing some other language feature like @disable this(). At the end it doesn't change anything for the compiler, the exact same work have to be done, simply on different entities. It can't be a 100% library feature as the work around @disable this shows. The difference is that @disable this() and friends allows implementing NonNull PLUS a host of other restricted types, whereas plopping NonNull in the language just stops there. Big difference. My point being that this is the exact same feature, from a compiler perspective. I think that ideally, nonnull pointer should be a core feature. Considering history, a library solution is preferable. But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler. No. See above. Tracking initialization, that's it.
Re: Wondering about errors…
On Mon, 2013-05-27 at 13:51 +0200, Adam D. Ruppe wrote: Yeah, me too. Phew, I'm so pleased it is not just me! My problem was forgetting an import. I am using std.array.split in one function and std.stdio.writef in a completely separate function. With split imported correctly everything compiles and runs as expected and required. Forgetting the import of split(*), I get: wc.d(11): Error: undefined identifier 'split' /usr/include/dmd/phobos/std/range.d(611): Error: static assert Cannot put a char[] into a Appender!(string) /usr/include/dmd/phobos/std/format.d(1436):instantiated from here: put!(Appender!(string), char[]) /usr/include/dmd/phobos/std/format.d(1338):instantiated from here: formatUnsigned!(Appender!(string), char) /usr/include/dmd/phobos/std/format.d(1312):instantiated from here: formatIntegral!(Appender!(string), ulong, char) /usr/include/dmd/phobos/std/conv.d(100):... (13 instantiations, -v to show) ... /usr/include/dmd/phobos/std/stdio.d(1784):instantiated from here: writefln!(char, immutable(int),immutable(int),immutable(int),string) wc.d(18):instantiated from here: writefln!(string,immutable(int),immutable(int),immutable(int),string) Which definitely results in a ***WTF***. How can a missing import cause this insane error report? If I use -v it looks even worse. (*) I am not a fan of importing all symbols from a module, so I always use selective imports. Whilst Python has no problem with imports and name spaces, Java, Scala, Groovy and D have horrible problems since the import imports into the current namespace. Obviously C++ is just a problem here due to textual inclusion rather than a module system. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ
On Monday, 27 May 2013 at 04:12:23 UTC, deadalnix wrote: On Sunday, 26 May 2013 at 23:38:33 UTC, Timothee Cour wrote: Is there any plan to support demangling of those: __ModuleInfoZ __initZ __arrayZ ? I have a lot of stuff that do not demangle properly with any tools. I give you one, just for fun :D D1d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement1004__T28parseDeclarationOrExpressionS6781d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7d! module6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement13__dgliteral23TS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ28parseDeclarationOrExpressionMFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAya! Z3lexMFAyaZ5LexerZC1d3ast9statement9Statement2029__T14parseAmbiguousS17161d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement1004__T28parseDeclarationOrExpressionS6781d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7d! module6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement13__dgliteral23TS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ28parseDeclarationOrExpressionM12__dgliteral9TS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__! lambda125TAyaZ3 Am I the only person that worries greatly about the length of symbols in D?
Re: Rust-based provocation :)
On Monday, 27 May 2013 at 14:36:59 UTC, Dicebot wrote: But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable. eh the question is what is most? Even my little 200 line thing has: functions, templates, scope closures, structs including operator overloading, static arrays, slices, pointers, __traits+ctfe, scope guards, switches, and more. I just now added basic classes and that wasn't too hard (copy/pasted some code from the real druntime for the typeinfo and so on). But it doesn't do AAs, throwing exceptions, dynamic arrays and other nice features. Looking at druntime's src, exceptions look hard, and while dynamic arrays, heap closures, and others can easily 'work', they will leak memory, so I don't think they will ever be really good without gc. Exceptions are doable though from what I can tell. Anyway I think this is enough to do some real programs and feel kinda nice. Surely no worse than C at least. Automatic memory allocation is widely known but emitting TypeInfo's for almost everything is as much painful. Yeah, the typeinfos are a pain in the butt, even trying to copy/paste it from druntime isn't that easy. I'm sure this would strike again if we actually tried writing a real program.
Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ
On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote: Am I the only person that worries greatly about the length of symbols in D? No, I do as well. My units of measurement project suffered from very non-negligible code bloat due to symbol name length, and even if that was a rather extraordinary endeavor to begin with, normal D code is affected just as well. For example, try this one from the std.algorithm unit tests: ——— _D3std5range4308__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std9algorithm987__T6joinerTS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T! 8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6joinerFS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8Seq! uenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6ResultTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range2008__T6RepeatTS3std9algorithm987__T6joinerTS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_! 6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6joinerFS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS!
Re: [article] Language Design Deal Breakers
On Mon, May 27, 2013 at 02:06:16AM -0400, Nick Sabalausky wrote: On Sun, 26 May 2013 17:38:21 -0700 Jonathan M Davis jmdavisp...@gmx.com wrote: On Sunday, May 26, 2013 11:46:53 Walter Bright wrote: Making non-nullable pointers is just plugging one hole in a cheese grater. LOL. That is highly quotable. As a person who very much enjoys a quality cheese, I find the practice of preventing null dereferences quite distasteful. *snerk* Thanks for the laugh! T -- IBM = I Blame Microsoft
Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ
On Monday, 27 May 2013 at 16:18:34 UTC, David Nadlinger wrote: On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote: Am I the only person that worries greatly about the length of symbols in D? No, I do as well. My units of measurement project suffered from very non-negligible code bloat due to symbol name length, and even if that was a rather extraordinary endeavor to begin with, normal D code is affected just as well. For example, try this one from the std.algorithm unit tests: ——— 13 kb of mangling ——— That's 13 kilobytes of data for a single symbol name! And the whole file also crashes the MinGW as when debug info generation is enabled, with the following rather hilarious error message: Fatal error: can't close N:/Build/Work/ldc2-llvm3.3-release/runtime/phobos_std_algorithm_debug.o: File too big So, yes, your guess on Twitter a few days ago was correct. David This also breaks forum software which shows one line string. Interesting issue here is whether mangling would be reduced (I guess it wouldn't).
Re: [article] Language Design Deal Breakers
Am 27.05.2013 09:13, schrieb Nick Sabalausky: On Mon, 27 May 2013 08:22:02 +0200 Paulo Pinto pj...@progtools.org wrote: On Monday, 27 May 2013 at 01:29:12 UTC, H. S. Teoh wrote: On Sun, May 26, 2013 at 05:20:59PM -0700, Ali Çehreli wrote: On 05/26/2013 01:04 PM, Walter Bright wrote: Yeah, I did the 'Soccer' one. http://www.handheldmuseum.com/Mattel/Soccer.htm That's before my time. :) I have played with ones similar to this though: http://www.handheldmuseum.com/Nintendo/Octopus.htm [...] Whoa. This one brings back the memories! Was this the one where you had to evade the tentacles and get to the sunken ship and back? I must've been a primary schoolboy when I played this game (never owned it though -- I used to visit my grand-uncle's electronics store and played it there). T Oh man! My first handheld, http://www.gameandwatch.com/screen/widescreen/manhole/index.html These were my first: http://www.handheldmuseum.com/Tiger/Pinball.htm http://www.handheldmuseum.com/Tiger/ElectronicFootball.htm http://www.handheldmuseum.com/Tiger/DoubleDragon.htm http://www.handheldmuseum.com/Tiger/NinjaGaiden.htm (I like this thread, it makes me feel comparatively young ;) ) I played the heck out of those pinball and football ones. Strange though, I had totally forgotten about those two until browsing that site just now. I also had the Castlevania II, MegaMan 2, and some racing one from a different company, not sure who. No idea what happened to any of them. (The watch one I remember I lost a lng time ago.) Many years later I participated in a very fun little Make an LCD-handheld style game homebrew competition with a GBA entry (got third place): http://pdroms.de/files/gameboyadvance/my-robot-v1-0 Very interesting, thanks for sharing.
Re: Why UTF-8/16 character encodings?
On Mon, May 27, 2013 at 04:17:06AM +0200, Wyatt wrote: On Sunday, 26 May 2013 at 21:23:44 UTC, H. S. Teoh wrote: I have been thinking about this idea of a reprogrammable keyboard, in that the keys are either a fixed layout with LCD labels on each key, or perhaps the whole thing is a long touchscreen, that allows arbitrary relabelling of keys (or, in the latter case, complete dynamic reconfiguration of layout). There would be some convenient way to switch between layouts, say a scrolling sidebar or roller dial of some sort, so you could, in theory, type Unicode directly. I haven't been able to refine this into an actual, implementable idea, though. I've given this domain a fair bit of thought, and from my perspective you want to throw hardware at a software problem. Have you ever used a Japanese input method? They're sort of a good exemplar here, wherein you type a sequence and then hit space to cycle through possible ways of writing it. So ame can become, あめ, 雨, 飴, etc. Right now, in addition to my learning, I also use it for things like α (アルファ) and Δ (デルタ). It's limited, but...usable, I guess. Sort of. The other end of this is TeX, which was designed around the idea of composing scientific texts with a high degree of control and flexibility. Specialty characters are inserted with backslash-escapes, like \alpha, \beta, etc. Now combine the two: An input method that outputs as usual, until you enter a character code which is substituted in real time to what you actually want. Example: values of \beta will give rise to dom! composes as values of β will give rise to dom! No hardware required; just a smarter IME. Like maybe this one: http://www.andonyar.com/rec/2008-03/mathinput/ (I'm honestly not yet sure how mature or usable that one is as I'm a UIM user, but it does serve as a proof of concept). I like this idea. It's certainly more feasible than reinventing the Optimus Maximus keyboard. :) I can write code for free, but engineering custom hardware is a bit beyond my abilities (and means!). If we go the software route, then one possible strategy might be: - Have a default mode that is whatever your default keyboard layout is (the usual 100+-key layout, or DVORAK, whatever.). - Assign one or two escape keys (not to be confused with the Esc key, which is something else) that allows you to switch mode. - Under the 1-key scheme, you'd use it to begin sequences like \beta, except that instead of the backslash \, you're using a dedicated key. These sequences can include individual characters (e.g. ESCbeta == β) or allow you to change the current input mode (e.g. ESCgrk to switch to a Greek layout that takes effect from that point onwards until you enter, say, ESCeng). For convenience, the sequence ESCESC can be shorthand for switching back to whatever the default layout is, so that if you mistype an escape sequence and end up in some strange unexpected layout mode, hitting ESC twice will reset it back to the default. - Under the 2-key scheme, you'd have one key dedicated for the occasional foreign character (ESC1beta == β), and the second key dedicated for switching layouts (thus allowing shorter sequences for switching between languages without fear of conflicting with single-character sequences, e.g., ESC2g for Greek). Perhaps the 1-key scheme is the simplest to implement. The capslock key is a good candidate, being conveniently located where your left little finger is, and having no real useful function in this day and age. The only drawback is no custom key labels. But perhaps that can be alleviated by hooking an escape sequence to toggle an on-screen visual representation of the current layout. Maybe ESC? can be assigned to invoke a helper utility that renders the current layout on the screen. T -- Don't get stuck in a closet---wear yourself out.
Re: Rust-based provocation :)
On 5/27/13 7:03 AM, Dicebot wrote: http://www.reddit.com/r/programming/comments/1f2nwe/zerors_rust_without_a_runtime/ It really makes me sad to see that Rust, despite being that immature and unstable is _already_ closer to embedded environments than D. Any possibility of a change? :P Of course there's a possibility of change. Like any aspect of a project like D, it needs a champion. Someone who decides it's important enough for them that they do the work required. It's extremely rare for something to happen that others claim they need just out of pure altruism. So, embedded support is important to you, right? What have you done to make it happen? My 2 cents, Brad
Re: Rust-based provocation :)
On Monday, 27 May 2013 at 17:18:33 UTC, Brad Roberts wrote: On 5/27/13 7:03 AM, Dicebot wrote: http://www.reddit.com/r/programming/comments/1f2nwe/zerors_rust_without_a_runtime/ It really makes me sad to see that Rust, despite being that immature and unstable is _already_ closer to embedded environments than D. Any possibility of a change? :P Of course there's a possibility of change. Like any aspect of a project like D, it needs a champion. Someone who decides it's important enough for them that they do the work required. It's extremely rare for something to happen that others claim they need just out of pure altruism. So, embedded support is important to you, right? What have you done to make it happen? My 2 cents, Brad
Re: [article] Language Design Deal Breakers
On 5/27/2013 2:17 AM, deadalnix wrote: But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler. Yes, it does stand, as there is a lot of other types that can benefit from @disable this. If notnull is a core feature, then only that works.
Re: Rust-based provocation :)
On Monday, 27 May 2013 at 17:18:33 UTC, Brad Roberts wrote: Of course there's a possibility of change. Like any aspect of a project like D, it needs a champion. Someone who decides it's important enough for them that they do the work required. It's extremely rare for something to happen that others claim they need just out of pure altruism. It is an issue that has some roots in language design. I have literally zero ideas how to fix it without changing the spec and this is out of random pull request / library capabilities. I would have been glad to work on this but only after at least some form of approval for chosen course of actions. Given the stability aim, it is unlikely to happen. Thus, provocation. So, embedded support is important to you, right? What have you done to make it happen? Helping the guys developing Volt fork of D2, within my limits. My 2 cents, Brad You're welcome :) P.S. Ugh, something is wrong with reCAPTCHA.
Re: New UTF-8 stride function
27-May-2013 01:04, Kiith-Sa пишет: WRT to the worse Linux64 case: I recommend infinite-cycling it and testing in perf top. (If you're on Ubuntu/derivative or maybe Debian, just type perf top, it will tell you what package to install, and once installed, perf top again, while the benchmark is running) You'll get a precise real-time line-wise (with ability to drill down to ASM) profile (like top, but for functions). With some command-line options (google linux perf), you can also look at cache misses, branch mispredictions, and so on. Compare that with the original version and you might find why it's slower. (Don't have time to test anything right now) Just tried it. Now I at least see that in 32bit my version is faster, whereas on 64bit it isn't (that is on DMD). One curiosity is that the code for ASCII case is the same yet even on English text the difference is about the same. Another one is that both function are not even partially inlined. -- Dmitry Olshansky
Re: Rust-based provocation :)
On Monday, 27 May 2013 at 15:45:04 UTC, Adam D. Ruppe wrote: On Monday, 27 May 2013 at 14:36:59 UTC, Dicebot wrote: But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable. eh the question is what is most? Even my little 200 line thing has: functions, templates, scope closures, structs including operator overloading, static arrays, slices, pointers, __traits+ctfe, scope guards, switches, and more. I am intrigued. I have tried to create something to support at least C with templates style but hit the wall when found out that templates currently require TypeInfo's. Looking at object.d source, it looks like you are generating TypeInfo stubs that can be optimized away, have I understood it right? P.S. I can't get to run your minimal.zip example because of object.d(87): Error: mismatch between compiler and object.d or object.di found. which does not really make sense in scope of line 87. Any ideas? Have changes all relevant stuff from x32 to x64 as far as I can see.
Re: [article] Language Design Deal Breakers
On Monday, 27 May 2013 at 17:41:37 UTC, Walter Bright wrote: On 5/27/2013 2:17 AM, deadalnix wrote: But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler. Yes, it does stand, as there is a lot of other types that can benefit from @disable this. If notnull is a core feature, then only that works. I never said that they are mutually exclusive. All the contrary, I say they are the same thing. And that if you have one, you have no reason not the have the other.
Long symbol names (Was: demangle doesn't work with...)
On Monday, 27 May 2013 at 16:18:34 UTC, David Nadlinger wrote: On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote: Am I the only person that worries greatly about the length of symbols in D? ——— snip ——— That's 13 kilobytes of data for a single symbol name! The symbols typically contain a lot of repeated sub strings. Perhaps there is a better mangling scheme that encodes it with some kind of prefix tree?
Re: Long symbol names (Was: demangle doesn't work with...)
On Monday, 27 May 2013 at 18:14:59 UTC, Peter Alexander wrote: On Monday, 27 May 2013 at 16:18:34 UTC, David Nadlinger wrote: On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote: Am I the only person that worries greatly about the length of symbols in D? ——— snip ——— That's 13 kilobytes of data for a single symbol name! The symbols typically contain a lot of repeated sub strings. Perhaps there is a better mangling scheme that encodes it with some kind of prefix tree? The way template are mangled in super redundant. This can probably be fixed easily, but this is a breakage.
Re: New UTF-8 stride function
27-May-2013 01:50, Juan Manuel Cabo пишет: And these are the results for the same linux 64bit system but compiling with -m32: This is mostly in agreement with what I have on my 4-core AMD Phenom. About the same on Core i5-3550 at work. Looks like I indeed need 'clock for clock' analysis to draw any conclusion. $ dmd -m32 -O -inline -release -noboundscheck fast_stride.d $ for a in *wiki*; do echo ; echo $a: ; ./fast_stride $a; done arwiki-latest-all-titles-in-ns0: stride 89362 myStride 49974 myStride 51140 stride 88308 dewiki-latest-all-titles-in-ns0: stride 138381 myStride 116971 myStride 116662 stride 139681 enwiki-latest-all-titles-in-ns0: stride 584787 myStride 490681 myStride 490909 stride 584694 ruwiki-latest-all-titles-in-ns0: stride 585372 myStride 333905 myStride 341274 stride 585050 --jm -- Dmitry Olshansky
Re: [article] Language Design Deal Breakers
On 05/27/2013 01:12 AM, Ziad Hatahet wrote: On Sun, May 26, 2013 at 3:48 PM, Timon Gehr timon.g...@gmx.ch mailto:timon.g...@gmx.ch wrote: IIRC the damage done by software bugs to US economy alone is estimated to be around 60 billion a year. One billion damage done by dereferenceable null pointers appears to be an optimistic estimate. Interesting. Source? :) -- Ziad Eg. here: http://www.ashireporter.org/HomeInspection/Articles/Software-Errors-Cost-U-S-Economy-59-5-Billion-Annually/740 I think many other studies estimate the cost to be higher.
Re: Long symbol names (Was: demangle doesn't work with...)
On Monday, 27 May 2013 at 18:22:41 UTC, deadalnix wrote: The way template are mangled in super redundant. This can probably be fixed easily, but this is a breakage. At this point, ABI stability is still is a long way out anyway. David
Re: [article] Language Design Deal Breakers
On 5/27/2013 11:27 AM, Timon Gehr wrote: On 05/27/2013 01:12 AM, Ziad Hatahet wrote: On Sun, May 26, 2013 at 3:48 PM, Timon Gehr timon.g...@gmx.ch mailto:timon.g...@gmx.ch wrote: IIRC the damage done by software bugs to US economy alone is estimated to be around 60 billion a year. One billion damage done by dereferenceable null pointers appears to be an optimistic estimate. Interesting. Source? :) -- Ziad Eg. here: http://www.ashireporter.org/HomeInspection/Articles/Software-Errors-Cost-U-S-Economy-59-5-Billion-Annually/740 I think many other studies estimate the cost to be higher. Nobody is doubting the high cost of software bugs. The doubt here is that null pointers are far and away the most common source of bugs (and I mean source, not just the symptom). The only way to resolve this would be to to go through the bug databases of resolved bugs and their fixes and actually count which ones were due to a null pointer that would have been caught by nonnull types.
Re: Discussion of TypeTuple naming
On 5/27/13, Diggory digg...@googlemail.com wrote: - The result of the change is zero existing code actually failing to compile. TypeTuple will simply show a deprecation warning if used with non-types. You are forgetting about performance. TypeTuple can be used *a lot* in generic code. If you add static checking for each tuple element you're going to slow down the compiler quite a bit. And you won't know this if you only sporadically use TypeTuple. - Any code that does use non-types with TypeTuple is using undocumented behaviour. It's not undocumented behavior, it's documented, e.g. The D Templates Book. - Almost all uses of TypeTuple are for dealing with types and so will be completely unaffected by the change. Where do you get this clarity that it's only used for types? Have you inspected all D libraries out there? - There's no necessity to ever actually completely remove the deprecated behaviour, the deprecation warning is enough. It's not, because now you're forced to always compile with the deprecation switch. --- All I see here is the problem with the actual *name* of the template. If it's so horrible to use this name, the simplest thing we can do is introduce an alias to TypeTuple, ala Seq or ExpressionTuple, or something similar. Of course TypeTuple is a misnomer, but it's way too late to change it now or even change its semantics. Even slowing it down by doing type-checking is a problem.
Re: New UTF-8 stride function
27-May-2013 01:13, Vladimir Panteleev пишет: On Sunday, 26 May 2013 at 20:49:36 UTC, Dmitry Olshansky wrote: It's the kind of thing that is tremendously hard to measure accurately since it depends on the workload, architecture and the time spent is very small. So don't take it by word I'm almost certain that something is amiss (compiler switches and whatnot). For such cases, I found Agner's benchmarking utilities to be very useful. They print exact CPU statistics, such as numbers of micro-ops, cache misses, mispredicted branches, etc. I've used them very successfully when tuning my appender implementation. Yes, Agner is da man. Just hoped I could postpone this but... welcome to the micro-optimization world I guess. To use them with D, I modified his C++ program to load a DLL and call a function, taking the DLL and function names from the command line. Original program: http://www.agner.org/optimize/testp.zip My patch (to load a DLL): http://dump.thecybershadow.net/5f55e8be5f8cd38ad60f218957ef24bb/PMCTestB.diff Usage example (sort of): https://github.com/CyberShadow/DAppenderResearch/blob/master/go-dll.bat Hope this helps :) Thanks, I'll try it out. But jezz I have win8 so I'd start with linux version :) -- Dmitry Olshansky
Re: New UTF-8 stride function
On 05/26/2013 10:49 PM, Dmitry Olshansky wrote: If there is anything that come out of UTF-8 discussion is that I decided to dust off my experimental implementation of UTF-8 stride function. Just for fun. The key difference vs std is in handling non-ASCII case. I'm replacing bsr intrinsic with a what I call an in-register lookup table (neat stuff that is a piece of cake, thx to CTFE). See unittest/benchmark here: https://gist.github.com/blackwhale/5653927 Looks promising. Test files I used: https://github.com/blackwhale/gsoc-bench-2012/blob/master/arwiki-latest-all-titles-in-ns0 https://github.com/blackwhale/gsoc-bench-2012/blob/master/dewiki-latest-all-titles-in-ns0 https://github.com/blackwhale/gsoc-bench-2012/blob/master/dewiki-latest-all-titles-in-ns0 https://github.com/blackwhale/gsoc-bench-2012/blob/master/ruwiki-latest-all-titles-in-ns0 These are huge and most likely the performance is limited by the memory bandwith.
Re: Discussion of TypeTuple naming
On Monday, May 27, 2013 21:13:10 Andrej Mitrovic wrote: On 5/27/13, Diggory digg...@googlemail.com wrote: - There's no necessity to ever actually completely remove the deprecated behaviour, the deprecation warning is enough. It's not, because now you're forced to always compile with the deprecation switch. That's not true anymore. Deprecations only print out warning messages by default, precisely so that we can deprecate things without breaking everyone's code. -d makes the compile shut up, but it is no longer required to get your code to compile. That being said, I don't really like the idea of deprecating something with the intention that it stick around forever. It just provides a smoother transition. All I see here is the problem with the actual *name* of the template. If it's so horrible to use this name, the simplest thing we can do is introduce an alias to TypeTuple, ala Seq or ExpressionTuple, or something similar. Of course TypeTuple is a misnomer, but it's way too late to change it now or even change its semantics. Even slowing it down by doing type-checking is a problem. Yeah. The only problem I see is the name. I don't see any real benefit in making it so that we have _three_ different types of compile time tuples, particularly when their uses tend to be fairly localized rather than being passed around through APIs and the like (if they get passed through APIs, they'd just be template or function argument lists), and any mismatch of types and expressions will result in an error pretty much instantly. So, holding both expressions and types isn't really a problem IMHO - particularly since that's what the built-in tuples do, and all TypeTuple really is is a template to let you create and manipulate the built-in tuples. So, if we change anything, we change the name via an alias and leave all of the semantics alone. But given how much TypeTuple is used and that the module is named std.typetuple, it would likely have to be a permanent alias, in which case you _still_ have to explain what TypeTuple is, and the gain of renaming it is minimal IMHO (it could even make things _worse_ by increasing the confusion by having multiple names). The name sucks, but I think that we're stuck with it at this point. For it to be worth it, we'd have to be willing to force everyone to change their code to use the new name, and for the most part, we're just not doing that sort of thing anymore. - Jonathan M Davis
Re: Why UTF-8/16 character encodings?
On Monday, 27 May 2013 at 02:17:08 UTC, Wyatt wrote: No hardware required; just a smarter IME. Perhaps something like the compose key? http://en.wikipedia.org/wiki/Compose_key
Re: New UTF-8 stride function
27-May-2013 23:21, Martin Nowak пишет: On 05/26/2013 10:49 PM, Dmitry Olshansky wrote: If there is anything that come out of UTF-8 discussion is that I decided to dust off my experimental implementation of UTF-8 stride function. Just for fun. The key difference vs std is in handling non-ASCII case. I'm replacing bsr intrinsic with a what I call an in-register lookup table (neat stuff that is a piece of cake, thx to CTFE). See unittest/benchmark here: https://gist.github.com/blackwhale/5653927 Looks promising. Cool, I'm not alone in this :) The only definitive results so far is that it takes less cycles on 32 bit. For me AMD CodeAnalyst confirms this is literally in cycles of up to 33% less with smaller samples in a loop. ASCII-only case seems to stay more or less the same (at least cycle-wise but not in time...) saving my sanity. These are huge and most likely the performance is limited by the memory bandwith. That could be it. I'll be making measurement on smaller samples of said files and spin on them. More tests to come tomorrow. -- Dmitry Olshansky
Re: Wondering about errors…
On 5/27/13 7:51 AM, Adam D. Ruppe wrote: Yeah, me too. I take a working program and add gf to the middle of it. Here's the errors: I'd say that deserves a bugzilla entry. Andrei
Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ
On 5/27/13 12:18 PM, David Nadlinger wrote: On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote: Am I the only person that worries greatly about the length of symbols in D? No, I do as well. My units of measurement project suffered from very non-negligible code bloat due to symbol name length, and even if that was a rather extraordinary endeavor to begin with, normal D code is affected just as well. For example, try this one from the std.algorithm unit tests: ——— _D3std5range4308__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std9algorithm987__T6joinerTS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__ T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6joinerFS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8Sequ enceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6ResultTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range2008__T6RepeatTS3std9algorithm987__T6joinerTS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typ econs12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatTS3std5range91__T6RepeatTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ6RepeatZ3ZipZ9MapResultZ6joinerFS3std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct744__T9MapResultS2353std9algorithm182__T16cartesianProductTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTiZ5TupleZ8SequenceZ16cartesianProduct16__funcliteral177TS3std5range472__T3ZipTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons12__T5TupleTkZ5TupleZ8SequenceTS3std5range57__T8SequenceVAyaa1_6eTS3std8typecons1
Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ
On Monday, 27 May 2013 at 20:14:35 UTC, Andrei Alexandrescu wrote: At some point Walter and I were talking about generating an MD hash for very long names. That has some disadvantages (i.e. no easy reverse lookup) but it may work. Surely a better solution would be to use a lossless compression? With the amount of repetition you should get very high ratios.
Re: Wondering about errors…
On 5/27/2013 4:32 AM, Russel Winder wrote: Using rdmd, it appears that the first error in the code can lead the parsing and template handling of everything following to be wrong. I keep finding that I am getting spurious errors about things nothing to do with the actual error, that simply go away when the real error is fixed. This would imply that most errors reported are generally spurious? The usual approach to handling errors in a compiler is to guess at what the user actually meant, repair the AST according to that guess, then continue on. Unfortunately, the guess is usually wrong and the result is cascaded errors, of which only the first is meaningful. DMD has been gradually switching over to a more novel approach, one that I haven't seen elsewhere. Once an error is discovered, the AST is marked as erroneous. That erroneous state propagates upwards to the root of the AST, and that any AST that relies on an erroneous AST is itself erroneous, and no further error messages are emitted for it. The result should be that only original sin errors are reported. This has already resulted in a great reduction of spurious error messages, but clearly we have more work to do.
Re: New UTF-8 stride function
On 05/27/2013 09:21 PM, Martin Nowak wrote: See unittest/benchmark here: https://gist.github.com/blackwhale/5653927 Looks promising. This will not detect 0xFF as invalid UTF-8 sequence. For sequences with 5 or 6 bytes, that aren't used for unicode, it will return a stride of 4.
Re: Why UTF-8/16 character encodings?
On Mon, May 27, 2013 at 09:59:52PM +0200, Vladimir Panteleev wrote: On Monday, 27 May 2013 at 02:17:08 UTC, Wyatt wrote: No hardware required; just a smarter IME. Perhaps something like the compose key? http://en.wikipedia.org/wiki/Compose_key I'm already using the compose key. But it only goes so far (I don't think compose key sequences cover all of unicode). Besides, it's impractical to use compose key sequences to write large amounts of text in some given language; a method of temporarily switching to a different layout is necessary. T -- Тише едешь, дальше будешь.
More on Component Programming
This simple task on Rosettacode site is useful to show some uses
of Phobos and the component programming recently discussed by
Walter (other languages use a different name to denote the same
idea).
Given a dictionary file of different words, it asks to find any
of the longest anagram pairs, that also share no equal chars in
the same position (so they are named deranged anagrams):
http://rosettacode.org/wiki/Anagrams/Deranged_anagrams#D
There are many ways to do this in D+Phobos. The following
solution is long, but it's quite fast (the warmed up run-time
is only about 0.03 seconds with a dictionary of about 200 KB, on
an old CPU core), I have chosen it over simple solutions because
it gives me a chance to discuss certain things:
import std.stdio, std.file, std.algorithm, std.string,
std.typecons, std.range, std.functional;
auto findDeranged(in string[] words) pure /*nothrow*/ {
//return words.pairwise.filter!(ww= ww[].zip.all!q{a[0] !=
a[1]});
Tuple!(string, string)[] result;
foreach (immutable i, const w1; words)
foreach (const w2; words[i + 1 .. $])
if (zip(w1, w2).all!q{ a[0] != a[1] })
result ~= tuple(w1, w2);
return result;
}
void main() {
Appender!(string[])[30] wClasses;
foreach (word;
std.algorithm.splitter(unixdict.txt.readText))
wClasses[$ - word.length] ~= word;
Longest deranged anagrams:.writeln;
foreach (words; wClasses[].map!q{ a.data
}.filter!(not!empty)) {
string[][const ubyte[]] anags; // Assume ASCII input.
foreach (w; words)
anags[w.dup.representation.sort().release.idup] ~= w;
auto pairs = anags.byValue.map!findDeranged.join;
if (!pairs.empty)
return writefln( %s, %s, pairs.front[]);
}
}
- - - - - - - - - - - -
That program contains five foreach loops. Foreach loops are not
evil and I like them, but for a certain kind of programming
(discussed recently by Walter, and also common in F# and other
languages) every time you use a for/foreach it's one small
failure for the standard library :-)
The following weird (untested and maybe buggy) program replaces
all the foreach loops with higher order functions and other
library functions. It can't be compiled because it uses some
things not yet present in Phobos (on the Rosettacode page there
is also a slower and simpler D solution of this problem that uses
only one foreach):
void main() {
import std.stdio, std.file, std.algorithm, std.string,
std.typecons, std.range, std.functional;
unixdict.txt
.readText
.splitter
.classify!q{ a.length }
.map!q{ a.values } // .byValue is almost OK.
.array
.schwartzSort!q{ -a[0].length }
.release
.map!(words = words
.classify!q{ a
.dup
.representation
.sort()
.release
.idup }
.byValue
.map!(words = words
.pairwise
.filter!(ww = ww[]
.zip
.all!q{ a[0] !=
a[1] }))
.join)
.filter(not!empty)
.front[]
.binaryReverseArgs!writefln( %s, %s);
}
A copy of the same code if the newsgroup has messed up the
formatting and indents, turning that code into a soup:
http://codepad.org/L4TyDkcQ
I am not suggesting you to write whole D script-like programs in
this strange style. But I think Phobos should offer all the tools
to write a program like this, because even if you don't want to
write a whole little program in this style, you sometimes want to
use some parts of it or some other parts of it, so I think all
the most common and distinct micro-patterns should be contained
in Phobos.
- - - - - - - - - - - -
binaryReverseArgs is in the std.functional module. Here it
allows the use of writefln in UFCS style, inverting the
formatting string position. I think I'd like a shorter and more
handy name for it. In Haskell it's named flip, and its usage is
not uncommon.
- - - - - - - - - - - -
classify is a simple function, that given a forward range of T
and an optional function T-K, returns an associative array
T[][K]. (Arrays are used by default as values. But maybe you can
optionally specify a different type of values, like Appenders,
Arrays, sets, etc). (Currently in Phobos the only function to
build an associative array is std.array.assocArray, but here we
need something different).
(http://d.puremagic.com/issues/show_bug.cgi?id=5502 ).
[1, 7, 6, 3, 2].classify!(x = x % 2 ? odd: even).writeln;
==
[odd: [1, 7, 3], even: [6, 2]]
- - - - - - - - - - - -
pairwise is a very useful lazy range similar to
cartesianProduct, but it yields only the ordered pairs, so
Re: [article] Language Design Deal Breakers
On Mon, 27 May 2013 16:55:54 +0200, deadalnix deadal...@gmail.com wrote: On Monday, 27 May 2013 at 14:36:26 UTC, Andrei Alexandrescu wrote: On 5/27/13 5:17 AM, deadalnix wrote: I'm saying that NonNull require language support, either by making it a first class entity, or by introducing some other language feature like @disable this(). At the end it doesn't change anything for the compiler, the exact same work have to be done, simply on different entities. It can't be a 100% library feature as the work around @disable this shows. The difference is that @disable this() and friends allows implementing NonNull PLUS a host of other restricted types, whereas plopping NonNull in the language just stops there. Big difference. My point being that this is the exact same feature, from a compiler perspective. I think that ideally, nonnull pointer should be a core feature. Considering history, a library solution is preferable. But the argument about compiler feature don't stand, as nonnull pointer and @disable this require the exact same processing in the compiler. No. See above. Tracking initialization, that's it. Well, yes. But it does so in a general way, rather than limit it to non-nullable pointers/references. If D had added non-nullable references only (no @disable this()), how would you go about creating a number that's guaranteed to be prime? Would you ask for that as a separate complier feature? -- Simen
Re: [article] Language Design Deal Breakers
On Mon, 27 May 2013 20:00:30 +0200, deadalnix deadal...@gmail.com wrote:
On Monday, 27 May 2013 at 17:41:37 UTC, Walter Bright wrote:
On 5/27/2013 2:17 AM, deadalnix wrote:
But the argument about compiler feature don't stand, as nonnull
pointer and
@disable this require the exact same processing in the compiler.
Yes, it does stand, as there is a lot of other types that can benefit
from @disable this. If notnull is a core feature, then only that works.
I never said that they are mutually exclusive. All the contrary, I say
they are the same thing. And that if you have one, you have no reason
not the have the other.
Ah, like that. Your posts could be read as 'non-nullable pointers give
the *exact* same benefits as does @disable this()', which is simply untrue.
Now, if we wanted to add compiler support for non-nullable references, many
more things would need to be decided - how do they look? Do they assert
non-nullness upon initialization/assignment, or are external checks
required?
Does new Foo() return a non-nullable reference? Must we also add scoped
non-nullness guarantees (if(foo != null) { /* foo is now implicitly
convertible to non-nullable */ })?
So, no. The stuff required to add @disable this() to the language is not
the
same that is required for non-nullable references. It's certainly an
important
part of it, but there's still more left, and it's going to make the
language
harder to implement. Adding a feature that lets non-nullable references be
added in a library is much better.
--
Simen
Re: [article] Language Design Deal Breakers
On Sun, 26 May 2013 10:50:25 +0200, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
On Sat, 25 May 2013 22:14:06 -0700
H. S. Teoh hst...@quickfur.ath.cx wrote:
D's unittest blocks have singlehandedly converted me from a
code-by-faith person full of every excuse to *not* write unittests, to
somebody habitually writing unittests.
Same here. And I'd bet it's a common story among D users.
Yup. Well, in D. I just love this:
void foo(Args args)
in {
} body {
} out {
} unittest {
}
I won't always use all of those (I'm no good at using contracts), but
writing
'} unittest {' at the end of a function has become second nature now.
Now, opening the unit test solution, checking out the right file, waiting
for a
minute while Irrational CludgeCase tries to download a possibly updated
version
of a file it should know is already on my disk, writing a new test while
occasionally glancing at the code on my other screen to remember what the
function did, then wait for ClearCase to accept my attempt to save to file,
before finally being able to run the test...
One of these is just... simpler. Better. More sane.
--
Simen
