Re: BlogPost: Implementing an asynchronous, epoll based network client
Nice, what will this be used for?
Re: Integer conversions too pedantic in 64-bit
Am 15.02.2011 22:49, schrieb Michel Fortin: On 2011-02-15 16:33:33 -0500, Walter Bright newshou...@digitalmars.com said: Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:ijeil4$2aso$3...@digitalmars.com... spir wrote: Having to constantly explain that _t means type, that size does not mean size, what this type is supposed to mean instead, what it is used for in core and stdlib functionality, and what programmers are supposed to use it for... isn't this a waste of our time? This, only because the name is mindless? No, because there is a vast body of work that uses size_t and a vast body of programmers who know what it is and are totally used to it. And there's a vast body who don't. And there's a vast body who are used to C++, so let's just abandon D and make it an implementation of C++ instead. I would agree that D is a complete waste of time if all it consisted of was renaming things. I'm just wondering whether 'size_t', because it is named after its C counterpart, doesn't feel too alien in D, causing people to prefer 'uint' or 'ulong' instead even when they should not. We're seeing a lot of code failing on 64-bit because authors used the fixed-size types which are more D-like in naming. Wouldn't more D-like names that don't look like relics from C -- something like 'word' and 'uword' -- have helped prevent those bugs by making the word-sized type look worth consideration? I am also for renaming it. It should begin with u to ensure everybody knows it's unsigned even if there's no signed counterpart. But what we definitely should avoid is to have two names for the same thing. It's the same mistake C++ did with inheriting everything from C and _adding_ it's own way. Mafi
Better assert without changing built-in assert
Hi,
I'm trying to improve the assertions. I tried the following
auto foo(bool var) {
return tuple(var, MyMessage);
}
void bar(bool var, string text) {
}
unittest {
bar(foo(true).expand);
//assert(foo(true).expand); // won't compile
}
void main() {}
$ dmd -unittest -run file.d
Commenting in the assert it fails with
Error: expression
tuple(foo(true)._field_field_0,foo(true)._field_field_1) of type (bool,
string) does not have a boolean value
assert behaves different when expanding tuples. Any explanations?
If one could do the above without writing the expand then it would
suggest a nice way of enhancing the build-in assert, I think.
If one cannot make it work without the .expand another option may be
to overload the built-in assert to handle tuples. This may be related to
http://d.puremagic.com/issues/show_bug.cgi?id=5547
Then one writes e.g.
assert(throws!MyException(expression))
or
assert(pred!(==)(a, b))
What do you think?
Jens
Re: std.range.zip performance
On 02/16/2011 03:36 AM, Andrei Alexandrescu wrote: Initial: 58 seconds. Eliminated the switch in popFront: 53s. Replaced emplace with assignment: 23s. Specialized emplace for non-struct types, reinserted: 23s. Eliminated the loop in empty (replaced with return ranges[0].empty;): 17s. I'm sure there are ways to further improve this, but there are a few difficulties. Each pass through the loop the code must transport values from the two arrays into a specific format and then distribute them for further calculation. Then, upon each popFront two words must be touched because arrays hold pointer+length, not pointer+pointer (as probably would be better since ranges are around). Nice analysis! Bearophile, is clay's zip func lazy. Else, it could explain part of its performance, don't you think? Denis
Re: Integer conversions too pedantic in 64-bit
On 02/16/2011 04:49 AM, Michel Fortin wrote: On 2011-02-15 22:41:32 -0500, Nick Sabalausky a@a.a said: I like nint. But is it unsigned or signed? Do we need 'unint' too? I think 'word' 'uword' would be a better choice. I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name. yop! Vote for word / uword. unint looks like meaning (x € R / not (x € Z)) lol! Denis -- _ vita es estrany spir.wikidot.com
Re: Integer conversions too pedantic in 64-bit
On 02/16/2011 03:07 AM, Jonathan M Davis wrote: On Tuesday, February 15, 2011 15:13:33 spir wrote: On 02/15/2011 11:24 PM, Jonathan M Davis wrote: Is there some low level reason why size_t should be signed or something I'm completely missing? My personal issue with unsigned ints in general as implemented in C-like languages is that the range of non-negative signed integers is half of the range of corresponding unsigned integers (for same size). * practically: known issues, and bugs if not checked by the language * conceptually: contradicts the obvious idea that unsigned (aka naturals) is a subset of signed (aka integers) It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either. I cannot prove it, but I really think you're wrong on that. First, the question of 1 bit. Think at this -- speaking of 64 bit size: * 99.999% of all uses of unsigned fit under 2^63 * To benefit from the last bit, you must have the need to store a value 2^63 = v 2^64 * Not only this, you must step on a case where /any/ possible value for v (depending on execution data) could be = 2^63, but /all/ possible values for v are guaranteed 2^64 This can only be a very small fraction of cases where your value does not fit in 63 bits, don't you think. Has it ever happened to you (even in 32 bits)? Something like: what a luck! this value would not (always) fit in 31 bits, but (due to this constraint), I can be sure it will fit in 32 bits (always, whatever input data it depends on). In fact, n bits do the job because (1) nearly all unsigned values are very small (2) the size used at a time covers the memory range at the same time. Upon efficiency, if unsigned is not a subset of signed, then at a low level you may be forced to add checks in numerous utility routines, the kind constantly used, everywhere one type may play with the other. I'm not sure where the gain is. Upon correctness, intuitively I guess (just a wild guess indeed) if unigned values form a subset of signed ones programmers will more easily reason correctly about them. Now, I perfectly understand the sacrifice of one bit sounds like a sacrilege ;-) (*) Denis (*) But you know, when as a young guy you have coded for 8 16-bit machines, having 63 or 64... -- _ vita es estrany spir.wikidot.com
Re: std.range.zip performance
Am 16.02.2011 10:25, schrieb spir: On 02/16/2011 03:36 AM, Andrei Alexandrescu wrote: Initial: 58 seconds. Eliminated the switch in popFront: 53s. Replaced emplace with assignment: 23s. Specialized emplace for non-struct types, reinserted: 23s. Eliminated the loop in empty (replaced with return ranges[0].empty;): 17s. I'm sure there are ways to further improve this, but there are a few difficulties. Each pass through the loop the code must transport values from the two arrays into a specific format and then distribute them for further calculation. Then, upon each popFront two words must be touched because arrays hold pointer+length, not pointer+pointer (as probably would be better since ranges are around). Nice analysis! Bearophile, is clay's zip func lazy. Else, it could explain part of its performance, don't you think? Denis why should it - what can lazyness help here?
Re: Integer conversions too pedantic in 64-bit
Jonathan M Davis wrote: It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either. Yup. A systems language is going to map closely onto the target machine, and that means its characteristics will show up in the language. Trying to pretend that arithmetic on integers is something other than what the CPU natively does just will not work.
Re: Integer conversions too pedantic in 64-bit
== Quote from spir (denis.s...@gmail.com)'s article On 02/16/2011 04:49 AM, Michel Fortin wrote: On 2011-02-15 22:41:32 -0500, Nick Sabalausky a@a.a said: I like nint. It's the machine integer, so I think the word 'mint' would better match your naming logic. Also, reminds me of this small advert: http://www.youtube.com/watch?v=zuy6o8YXzDo ;) But is it unsigned or signed? Do we need 'unint' too? I think 'word' 'uword' would be a better choice. I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name. yop! Vote for word / uword. unint looks like meaning (x € R / not (x € Z)) lol! Denis word/uword sits well with my understanding.
Re: Better assert without changing built-in assert
Jens Mueller Wrote:
Hi,
I'm trying to improve the assertions. I tried the following
auto foo(bool var) {
return tuple(var, MyMessage);
}
void bar(bool var, string text) {
}
unittest {
bar(foo(true).expand);
//assert(foo(true).expand); // won't compile
}
void main() {}
$ dmd -unittest -run file.d
Commenting in the assert it fails with
Error: expression
tuple(foo(true)._field_field_0,foo(true)._field_field_1) of type (bool,
string) does not have a boolean value
assert behaves different when expanding tuples. Any explanations?
If one could do the above without writing the expand then it would
suggest a nice way of enhancing the build-in assert, I think.
If one cannot make it work without the .expand another option may be
to overload the built-in assert to handle tuples. This may be related to
http://d.puremagic.com/issues/show_bug.cgi?id=5547
Then one writes e.g.
assert(throws!MyException(expression))
or
assert(pred!(==)(a, b))
What do you think?
Jens
Or like this:
import std.conv;
string cat(T...)(T ts)
{
string s;
foreach(t; ts)
s ~= to!string(t) ~ ;
return s;
}
unittest
{
...
assert(a==b, cat(a,b));
}
Re: Better assert without changing built-in assert
On 2/16/11 5:04 AM, Jim wrote:
Jens Mueller Wrote:
Hi,
I'm trying to improve the assertions. I tried the following
auto foo(bool var) {
return tuple(var, MyMessage);
}
void bar(bool var, string text) {
}
unittest {
bar(foo(true).expand);
//assert(foo(true).expand); // won't compile
}
void main() {}
$ dmd -unittest -run file.d
Commenting in the assert it fails with
Error: expression
tuple(foo(true)._field_field_0,foo(true)._field_field_1) of type (bool,
string) does not have a boolean value
assert behaves different when expanding tuples. Any explanations?
If one could do the above without writing the expand then it would
suggest a nice way of enhancing the build-in assert, I think.
If one cannot make it work without the .expand another option may be
to overload the built-in assert to handle tuples. This may be related to
http://d.puremagic.com/issues/show_bug.cgi?id=5547
Then one writes e.g.
assert(throws!MyException(expression))
or
assert(pred!(==)(a, b))
What do you think?
Jens
Or like this:
import std.conv;
string cat(T...)(T ts)
{
string s;
foreach(t; ts)
s ~= to!string(t) ~ ;
return s;
}
unittest
{
...
assert(a==b, cat(a,b));
}
There's already text in std.conv with the same semantics.
{
assert(a==b, text(a,b));
}
Andrei
Re: shared libraries in D
== Quote from Christian Kamm (kamm-incasoftw...@removethis.de)'s article Iain Buclaw wrote: == Quote from Christian Kamm (kamm-incasoftw...@removethis.de)'s article Iain Buclaw wrote: Will be making shared libraries default in GDC pretty soon now... Did you adjust the GC to check the shared libraries' data sections for references? When we looked at this for LDC that turned out to slow down GC runs significantly. I'm pretty sure bearophile benchmarked it at the time. As far as I remember the main problem was that we were scanning all data sections - even of plain C libraries. Regards, Christian When adding more ranges in the GC to check, slowdowns are inevitable. So far in my personal testing, the slowdowns seem pretty negligible in comparison (never more than 0.300 seconds, though that could be a sign that I'm not pushing it in the right way). To prevent the GC from scanning C libraries, I've added an extra check to only add ranges that have a D module inside them. That sounds good. I was asking because I didn't see any code like this in http://bitbucket.org/goshawk/gdc - which repository is this in? Christian It's currently on my local workstation, all mashed together with the D2 beta merge. I have faith that my workstation won't crash and die in the meantime touchwood and will sift through it all (and break it down into sizeable commits) once I'm satisfied that there's nothing more I can do. Regards Iain
Re: Better assert without changing built-in assert
Jens Mueller Wrote:
Hi,
I'm trying to improve the assertions. I tried the following
auto foo(bool var) {
return tuple(var, MyMessage);
}
void bar(bool var, string text) {
}
unittest {
bar(foo(true).expand);
//assert(foo(true).expand); // won't compile
}
void main() {}
$ dmd -unittest -run file.d
Commenting in the assert it fails with
Error: expression
tuple(foo(true)._field_field_0,foo(true)._field_field_1) of type (bool,
string) does not have a boolean value
assert behaves different when expanding tuples. Any explanations?
If one could do the above without writing the expand then it would
suggest a nice way of enhancing the build-in assert, I think.
If one cannot make it work without the .expand another option may be
to overload the built-in assert to handle tuples. This may be related to
http://d.puremagic.com/issues/show_bug.cgi?id=5547
Then one writes e.g.
assert(throws!MyException(expression))
or
assert(pred!(==)(a, b))
What do you think?
Jens
Or like this:
import std.conv;
string cat(T...)(T ts)
{
string s;
foreach(t; ts)
s ~= to!string(t) ~ ;
return s;
}
unittest
{
...
assert(a==b, cat(a,b));
}
Re: Integer conversions too pedantic in 64-bit
spir wrote: On 02/16/2011 03:07 AM, Jonathan M Davis wrote: On Tuesday, February 15, 2011 15:13:33 spir wrote: On 02/15/2011 11:24 PM, Jonathan M Davis wrote: Is there some low level reason why size_t should be signed or something I'm completely missing? My personal issue with unsigned ints in general as implemented in C-like languages is that the range of non-negative signed integers is half of the range of corresponding unsigned integers (for same size). * practically: known issues, and bugs if not checked by the language * conceptually: contradicts the obvious idea that unsigned (aka naturals) is a subset of signed (aka integers) It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either. I cannot prove it, but I really think you're wrong on that. First, the question of 1 bit. Think at this -- speaking of 64 bit size: * 99.999% of all uses of unsigned fit under 2^63 * To benefit from the last bit, you must have the need to store a value 2^63 = v 2^64 * Not only this, you must step on a case where /any/ possible value for v (depending on execution data) could be = 2^63, but /all/ possible values for v are guaranteed 2^64 This can only be a very small fraction of cases where your value does not fit in 63 bits, don't you think. Has it ever happened to you (even in 32 bits)? Something like: what a luck! this value would not (always) fit in 31 bits, but (due to this constraint), I can be sure it will fit in 32 bits (always, whatever input data it depends on). In fact, n bits do the job because (1) nearly all unsigned values are very small (2) the size used at a time covers the memory range at the same time. Upon efficiency, if unsigned is not a subset of signed, then at a low level you may be forced to add checks in numerous utility routines, the kind constantly used, everywhere one type may play with the other. I'm not sure where the gain is. Upon correctness, intuitively I guess (just a wild guess indeed) if unigned values form a subset of signed ones programmers will more easily reason correctly about them. Now, I perfectly understand the sacrifice of one bit sounds like a sacrilege ;-) (*) Denis (*) But you know, when as a young guy you have coded for 8 16-bit machines, having 63 or 64... Exactly. It is NOT the same as the 8 16 bit case. The thing is, the fraction of cases where the MSB is important has been decreasing *exponentially* from the 8-bit days. It really was necessary to use the entire address space (or even more, in the case of segmented architecture on the 286![1]) to measure the size of anything. D only supports 32 bit and higher, so it isn't hamstrung in the way that C is. Yes, there are still cases where you need every bit. But they are very, very exceptional -- rare enough that I think the type could be called __uint, __ulong. [1] What was size_t on the 286 ? Note that in the small memory model (all pointers 16 bits) it really was possible to have an object of size 0x_, because the code was in a different address space.
Re: std.range.zip performance
Andrei: I'm sure there are ways to further improve this, but there are a few difficulties. Each pass through the loop the code must transport values from the two arrays into a specific format and then distribute them for further calculation. Then, upon each popFront two words must be touched because arrays hold pointer+length, not pointer+pointer (as probably would be better since ranges are around). HOFs as zip/map/filter aren't D built-ins as in Python, but they are basic language constructs. If the D front-end becomes a bit aware of what a zip is, it probably becomes able to optimize away most or all those data movements. The performance difference between the #3, #4, #5 and #5b (without zip constructor) shows there's more space for improvements, optimization-wise. In the Haskell Prelude (a standard module imported and compiled before any user code) shows the implementation of zip(l1,l2) and zip3(l1,l2,l3): zip :: [a] - [b] - [(a,b)] zip = zipWith (,) zip3 :: [a] - [b] - [c] - [(a,b,c)] zip3 = zipWith3 (,,) zipWith :: (a-b-c) - [a]-[b]-[c] zipWith z (a:as) (b:bs) = z a b : zipWith z as bs zipWith _ _ _= [] zipWith3 :: (a-b-c-d) - [a]-[b]-[c]-[d] zipWith3 z (a:as) (b:bs) (c:cs) = z a b c : zipWith3 z as bs cs zipWith3 _ _ _ _ = [] They are tiny compared to Phobos code. They are efficient enough, and they have no corner cases. -- spir: is clay's zip func lazy. It seems lazy, it's not an array of records, and the printing function refuses to print it. Bye, bearophile
Re: Integer conversions too pedantic in 64-bit
On Feb 16, 11 11:49, Michel Fortin wrote: On 2011-02-15 22:41:32 -0500, Nick Sabalausky a@a.a said: I like nint. But is it unsigned or signed? Do we need 'unint' too? I think 'word' 'uword' would be a better choice. I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name. 'word' may be confusing to Windows programmers because in WinAPI a 'WORD' means an unsigned 16-bit integer (aka 'ushort'). http://msdn.microsoft.com/en-us/library/cc230402(v=PROT.10).aspx
Re: Integer conversions too pedantic in 64-bit
On Tue, 15 Feb 2011 18:18:22 -0500, Rainer Schuetze r.sagita...@gmx.de wrote: Steven Schveighoffer wrote: In addition size_t isn't actually defined by the compiler. So the library controls the size of size_t, not the compiler. This should make it extremely portable. I do not consider the language and the runtime as completely seperate when it comes to writing code. You are right, in some cases the runtime just extends the compiler features. However, I believe the runtime is meant to be used in multiple compilers. I would expect object.di to remain the same. Probably core too. This should be easily checkable with the newer gdc, which I believe uses a port of druntime. BTW, though defined in object.di, size_t is tied to some compiler internals: alias typeof(int.sizeof) size_t; and the compiler will make assumptions about this when creating array literals. This is true. This makes it depend on the compiler. However, I believe the spec is concrete about what the sizeof type should be (if not, it should be made concrete). I don't have a perfect solution, but maybe builtin arrays could be limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless signed/unsigned conversions), so the normal type to be used is still int. Ranges should adopt the type sizes of the underlying objects. No, this is too limiting. If I have 64GB of memory (not out of the question), and I want to have a 5GB array, I think I should be allowed to. This is one of the main reasons to go to 64-bit in the first place. Yes, that's the imperfect part of the proposal. An array of ints could still use up to 16 GB, though. Unless you cast it to void[]. What would exactly happen there, a runtime error? Which means a runtime check for an implicit cast? I don't think it's really an option to make array length always be uint (or int). I wouldn't have a problem with using signed words for length. using more than 2GB for one array in 32-bit land would be so rare that having to jump through special hoops would be fine by me. Obviously for now, 2^63-1 sized arrays is plenty room for todays machines in 64-bit land. What bothers me is that you have to deal with these portability issues from the very moment you store the length of an array elsewhere. Not a really big deal, and I don't think it will change, but still feels a bit awkward. Java defines everything to be the same regardless of architecture, and the result is you just can't do certain things (like have a 5GB array). A system-level language should support the full range of architecture capabilities, so you necessarily have to deal with portability issues. If you want a super-portable language that runs the same everywhere, use an interpreted/bytecode language like Java, .Net or Python. D is for getting close to the metal. I see size_t as a way to *mostly* make things portable. It is not perfect, and really cannot be. It's necessary to expose the architecture so you can adapt to it, there's no getting around taht. Really, it's rare that you have to use it anyways, most should use auto. -Steve
Re: Integer conversions too pedantic in 64-bit
On Tue, 15 Feb 2011 16:50:21 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:ijesem$brd$1...@digitalmars.com... Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqx78nkceav7ka@steve-laptop... size_t works, it has a precedent, it's already *there*, just use it, or alias it if you don't like it. One could make much the same argument about the whole of C++. It works, it has a precedent, it's already *there*, just use it. The whole reason I came to D was because, at the time, D was more interested in fixing C++'s idiocy than just merely aping C++ as the theme seems to be now. Nick, this isn't a feature, it's not a design, it's not a whole language, it's a *single name*, one which is easily changed if you want to change it. module nick; alias size_t wordsize; Now you can use it anywhere, it's sooo freaking simple, I don't understand the outrage. BTW, what I meant about it's already there is that any change to the size_t name would have to have some benefit besides it's a different name because it will break any code that currently uses it. If this whole argument is to just add another alias, then I'll just stop reading this thread since it has no point. -Steve
Re: Integer conversions too pedantic in 64-bit
On 02/16/2011 12:21 PM, Don wrote: spir wrote: On 02/16/2011 03:07 AM, Jonathan M Davis wrote: On Tuesday, February 15, 2011 15:13:33 spir wrote: On 02/15/2011 11:24 PM, Jonathan M Davis wrote: Is there some low level reason why size_t should be signed or something I'm completely missing? My personal issue with unsigned ints in general as implemented in C-like languages is that the range of non-negative signed integers is half of the range of corresponding unsigned integers (for same size). * practically: known issues, and bugs if not checked by the language * conceptually: contradicts the obvious idea that unsigned (aka naturals) is a subset of signed (aka integers) It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either. I cannot prove it, but I really think you're wrong on that. First, the question of 1 bit. Think at this -- speaking of 64 bit size: * 99.999% of all uses of unsigned fit under 2^63 * To benefit from the last bit, you must have the need to store a value 2^63 = v 2^64 * Not only this, you must step on a case where /any/ possible value for v (depending on execution data) could be = 2^63, but /all/ possible values for v are guaranteed 2^64 This can only be a very small fraction of cases where your value does not fit in 63 bits, don't you think. Has it ever happened to you (even in 32 bits)? Something like: what a luck! this value would not (always) fit in 31 bits, but (due to this constraint), I can be sure it will fit in 32 bits (always, whatever input data it depends on). In fact, n bits do the job because (1) nearly all unsigned values are very small (2) the size used at a time covers the memory range at the same time. Upon efficiency, if unsigned is not a subset of signed, then at a low level you may be forced to add checks in numerous utility routines, the kind constantly used, everywhere one type may play with the other. I'm not sure where the gain is. Upon correctness, intuitively I guess (just a wild guess indeed) if unigned values form a subset of signed ones programmers will more easily reason correctly about them. Now, I perfectly understand the sacrifice of one bit sounds like a sacrilege ;-) (*) Denis (*) But you know, when as a young guy you have coded for 8 16-bit machines, having 63 or 64... Exactly. It is NOT the same as the 8 16 bit case. The thing is, the fraction of cases where the MSB is important has been decreasing *exponentially* from the 8-bit days. It really was necessary to use the entire address space (or even more, in the case of segmented architecture on the 286![1]) to measure the size of anything. D only supports 32 bit and higher, so it isn't hamstrung in the way that C is. Yes, there are still cases where you need every bit. But they are very, very exceptional -- rare enough that I think the type could be called __uint, __ulong. Add this: in the case where one needs exactly all 64 bits, then the proper type to use is exactly ulong. [1] What was size_t on the 286 ? Note that in the small memory model (all pointers 16 bits) it really was possible to have an object of size 0x_, because the code was in a different address space. Denis -- _ vita es estrany spir.wikidot.com
Re: Integer conversions too pedantic in 64-bit
On 2/16/11 9:09 AM, Steven Schveighoffer wrote: On Tue, 15 Feb 2011 16:50:21 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message module nick; alias size_t wordsize; Now you can use it anywhere, it's sooo freaking simple, I don't understand the outrage. But that is somewhat selfish. Given size_t causes dissatisfaction with a lot of people, people will start create their won aliases and then you end up having 5 different versions of it around. If this type is an important one for writing architecture independent code that can take advantage of architectural limits, then we better don't have 5 different names for it in common code. I don't think changing stuff like this should be distruptive. size_t can be marked deprecated and could be removed in a future release, giving people enough time to adapt. Furthermore, with the 64-bit support in dmd approaching, this is the time to do it, if ever.
Re: Stupid little iota of an idea
On 11/02/2011 23:55, Andrei Alexandrescu wrote: On 2/11/11 7:07 AM, foobar wrote: Andrei Alexandrescu Wrote: I don't find the name iota stupid. Andrei I want to make a few comments, arising from several different posts in this discussion. First, before this discussion that Ary started, I had heard the iota function being mentioned a few times in other NG posts, and although I wasn't 100% sure of what it did, I did deduce it returned a sequence of numbers (in range API). And also I assumed this number sequence was related to some concept in mathematics called iota (like a Fibonacci sequence, or the factors in a Taylor series, etc.). I found now that such is not the case, the term iota as used in D was introduced by the APL language, but is not defined or well-known in mathematics academia. Generally speaking I agree with with Ary's idea of having better, more descriptive names. But I am not sure I agree what would be a better alternative. I find the name iota to be meaningless, but range for example is worse because its meaning conflicts with the general meaning of D ranges. Conflicts in the sense that although iota(...) does return a range, it does something quite more specific. I would rather introduce a new term (iota), than use a confusing or overlapping one like range (or even interval). I might prefer the function to be called numberSequence or numberSeq, but I don't yet have a strong enough opinion to actually cast a vote. -- Bruno Medeiros - Software Engineer
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
On 11/02/2011 23:30, Walter Bright wrote: Bruno Medeiros wrote: but seriously, even if I am connected to the Internet I cannot code with my laptop only, I need it connected to a monitor, as well as a mouse, (and preferably a keyboard as well). I found I can't code on my laptop anymore; I am too used to and needful of a large screen. Yeah, that was my point as well. The laptop monitor is too small for coding, (unless one has a huge laptop). -- Bruno Medeiros - Software Engineer
Re: Integer conversions too pedantic in 64-bit
On Wed, 16 Feb 2011 09:23:09 -0500, gölgeliyele usul...@gmail.com wrote: On 2/16/11 9:09 AM, Steven Schveighoffer wrote: On Tue, 15 Feb 2011 16:50:21 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message module nick; alias size_t wordsize; Now you can use it anywhere, it's sooo freaking simple, I don't understand the outrage. But that is somewhat selfish. Given size_t causes dissatisfaction with a lot of people, people will start create their won aliases and then you end up having 5 different versions of it around. If this type is an important one for writing architecture independent code that can take advantage of architectural limits, then we better don't have 5 different names for it in common code. Sir, you've heard from the men who don't like size_t. But what about the silent masses who do? So we change it. And then people don't like what it's changed to, for example, I might like size_t or already have lots of code that uses size_t. So I alias your new name to size_t in my code. How does this make things better/different? bearophile doesn't like writeln. He uses something else in his libs, it's just an alias. Does that mean we should change writeln? IT'S A NAME!!! one which many are used to using/knowing. Whatever name it is, you just learn it, and once you know it, you just use it. If we hadn't been using it for the last 10 years, I'd say, sure, let's have a vote and decide on a name. You can't please everyone with every name. size_t isn't so terrible that it needs to be changed, so can we focus efforts on actual important things? This is the sheddiest bikeshed argument I've seen in a while. I'm done with this thread... -Steve
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
On 11/02/2011 18:31, Michel Fortin wrote: Ideally, if one wants to do push but the ancestor history is incomplete, the VCS would download from the central repository whatever revision/changeset information was missing. Actually, there's no central repository in Git. That stuff about DVCS not having a central repository is another thing that is being said a lot, but is only true in a very shallow (and non-useful) way. Yes, in DVCS there are no more working copies as in Subversion, now everyone's working copy is a full fledged repository/clone that in technical terms is peer of any other repository. However, from an organizational point of view in a project, there is always going to be a central repository. The one that actually represents the product/application/library, where the builds and releases are made from. (Of course, there could be more than one central repository if there are multiple kinds of releases like stable/experimental, or forks of the the product, etc.) Maybe the DVCS world likes the term public/shared repository better, but that doesn't make much difference. -- Bruno Medeiros - Software Engineer
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
On 11/02/2011 13:14, Jean Crystof wrote: Since you're a SVN advocate, please explain how well it works with 2500 GB of asset files? I'm not an SVN advocate. I have started using DVCSs over Subversion, and generally I agree they are better, but what I'm saying is that they are not all roses... it is not a complete win-win, there are a few important cons, like this one. -- Bruno Medeiros - Software Engineer
Re: Integer conversions too pedantic in 64-bit
On 2/16/11 9:45 AM, Steven Schveighoffer wrote: I'm done with this thread... -Steve Ok, I don't want to drag on. But there is a reason why we have a style. size_t is against the D style and obviously does not match. I use size_t as much as Walter does in my day job, and I even like it. It just does not fit into D's type names. That is all.
Re: 0nnn octal notation considered harmful
On 12/02/2011 18:27, Don wrote: spir wrote: snip Copying a string'ed integer is indeed not the only this notation is bug-prone: prefixing a number with '0' should not change its value (!). Indeed. Even more confusing is that when it's a floating point it doesn't. But see http://d.puremagic.com/issues/show_bug.cgi?id=3251 Several programming languages switched to another notation; like 0onnn, which is consistent with common hex bin notations and cannot lead to misinterpretation. Such a change would be, I guess, backward compatible; and would not be misleading for C coders. Indeed, does anyone know why the 0xxx notation was chosen in the first place? Octal should just be dropped entirely. Retaining built-in octal literals is like retaining support for EBCDIC. It's a relic of a time before hexadecimal was invented. I once recall hearing that octal's main use lay on old mainframes that worked in 15-bit units. But it lives on in Unix file permission settings. And is it still the form of CompuServe user IDs? Stewart.
Re: D vs Go on reddit
On 10/02/2011 21:38, Ulrik Mikaelsson wrote:
2011/2/10 Bruno Medeirosbrunodomedeiros+spam@com.gmail:
I'm very much a fan of simple and orthogonal languages. But this statement
has a big problem: it's not clear what one actually considers to be simple
and orthogonal. What people consider to be orthogonal can vary not only a
little, but actually a lot. Sometimes it can actually vary so much as to be
on opposite sides. I remember seeing that first hand here on D: two people
were arguing for opposing things in D (I don't remember the particular
issue, but one was probably a greater language change, the other as for the
status quo, or a minor change from the status quo), and explicitly argued
that their alternative was more orthogonal! I remember thinking that one was
stretching the notion of orthogonality a bit further than the other, but I
didn't find any of them to actually be incorrect.
For the sake of discussion I'll define orthogonal as non-redundant.
For instance, orthogonal dimensions in a coordinate-system is when the
dimension is completely unrelated to other dimensions, i.e. there is
no redundancy in the coordinate-system. Likewise orthogonality in a
language in my definition means it does not have redundancy in
features.
Now, the problem with orthogonality is that, it is not good for
exploiting 80/20 optimisations.
Example: for most (imperative) languages, you'll somewhere have the
general way of iteration;
list x;
int i = 0;
while (i x.length) {
// do something with x[i];
i++;
}
Now, if the language is truly orthogonal, you cannot add the foreach
(x in list)-feature, since it's a redundant way of doing a subset of
the same things. Yet, it's highly likely practical thinking says that
for most programs in the language, 95% of all iteration will be
list-iteration, where the foreach-version is both shorter to write,
easier to read, and not as prone to a typo.
Ok. However, my notion of orthogonality is fairly different from that one.
--
Bruno Medeiros - Software Engineer
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
On Wed, 2011-02-16 at 14:51 +, Bruno Medeiros wrote: [ . . . ] That stuff about DVCS not having a central repository is another thing that is being said a lot, but is only true in a very shallow (and non-useful) way. Yes, in DVCS there are no more working copies as in Subversion, now everyone's working copy is a full fledged repository/clone that in technical terms is peer of any other repository. However, from an organizational point of view in a project, there is always going to be a central repository. The one that actually represents the product/application/library, where the builds and releases are made from. (Of course, there could be more than one central repository if there are multiple kinds of releases like stable/experimental, or forks of the the product, etc.) Definitely the case. There can only be one repository that represents the official state of a given project. That isn't really the issue in the move from CVCS systems to DVCS systems. Maybe the DVCS world likes the term public/shared repository better, but that doesn't make much difference. In the Bazaar community, and I think increasingly in Mercurial and Git ones, people talk of the mainline or master. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D vs Go on reddit
On 11/02/2011 03:08, Nick Sabalausky wrote: Bruno Medeirosbrunodomedeiros+spam@com.gmail wrote in message news:ij1guf$694$1...@digitalmars.com... You guys are way on the wrong track here. I'm very much a fan of simple and orthogonal languages. But this statement has a big problem: it's not clear what one actually considers to be simple and orthogonal. What people consider to be orthogonal can vary not only a little, but actually a lot. Sometimes it can actually vary so much as to be on opposite sides. I remember seeing that first hand here on D: two people were arguing for opposing things in D (I don't remember the particular issue, but one was probably a greater language change, the other as for the status quo, or a minor change from the status quo), and both explicitly argued that their alternative was more orthogonal! I remember thinking that one was stretching the notion of orthogonality a bit further than the other, but I didn't find any of them to actually be incorrect. So people, please don't dismiss out of hand the principle that orthogonality is a very worthwhile design goal. Rather, this principle needs to be understood and applied in a more concrete and objective manner. It cannot be described in a simplistic one-liner (more orthogonality is good. kthxbye!). For starters, it only makes sense to evaluate the orthogonality of a language alongside the expressive power of the language. Otherwise the family of languages used in Turing machines (P'', and even brainfuck) would be the unmatched best languages in terms of orthogonality. (the whole language can be described in a few paragraphs... so simple!) On 09/02/2011 13:01, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:iicfaa$23j7$1...@digitalmars.com... http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would have taught people that extreme simplicity/orthogonality is a stupid way to design a language that's intended to be used in the real world. But people keep flocking to that silver bullet anyway. Eh?? What exactly has JS, Haskell, LISP and Java taught us in terms of designing a language that's intended to be used in the real world? You seem to be implying these language did something massively wrong... However Java became very popular and widespread (and the version of the language when such happened, 1.3-1.4, was very similar to Java v1.2). JavaScript is also quite popular and widespread, for a scripting language at least (and not only in web/HTML). Only Lisp has widely been acknowledge as a failure. Dunno about Haskell, maybe the jury is still out on that one. But in any case your argument is already starting off in a bad way (in at least a 50% fuzzy manner). Even if we were to imagine that all those 4 languages had been a failure, or become obsolete, your argument still wouldn't be much useful. Because: Java - Yes, Java is simpler than it's predecessor (C/C++), but not in orthogonality. Java has less capabilities/functionality (like manipulating pointers, or creating structs), it is not more orthogonal. LISP - LISP syntax is very orthogonal, but it pushes it the extreme, hurting readability. Also can one also say that LISP *semantics* are also very orthogonal? Even with the macro system, I doubt that is entirely the case for the generality of the language, although the true answer for this would depend on the particular dialect of LISP (my experience has been with Common Lisp and Scheme). Don't know enough about Haskell. (And probably neither do you. Or anyone else for that matter, except /that/ handful of people in the whole world? :P ) As for JavaScript, well, this one I do agree, it is incredibly orthogonal, one of the very few languages I would say that, and quite beautiful in that way. But regardless of all this, Lisp and JavaScript are not comparable to D with regards to trying to evaluate how much orthogonality is good or bad... because they are not even statically typed languages (also in the case of JavaScript there is no metaprogramming). Because of this, it will be much, much, more easy for them to orthogonal. Yet, if they fail, can we say it was the fault of being orthogonal? It could have been plenty of other things in the language design. (or even something entirely outside the design) In my view of the /worthiness of orthogonality/, it only is useful to compare the simplicity of languages when the capabilities, functionality, and expressive power of such languages are more or less comparable... You seem to misunderstand. I never said that orthogonality or simplicity was bad. I just said that it was stupid to equate more simple/orthogonal with better and less simple/orthogonal with worse. Ie, I was saying exactly the same thing about orthoginality as what you're saying. I beleive that as a consequence, it's dumb to make simple/orthogonal
Re: What Makes A Programming Language Good
On 04/02/2011 20:55, bearophile wrote: Bruno Medeiros: That language ecosystems are what matter, not just the language itself. This is true, but only once your language is already very good :-) Bye, bearophile I disagree. I think an average language with an average toolchain (I'm not even considering the whole ecosystem here, just the toolchain - compilers, debuggers, IDEs, profilers, and some other tools) will be better than a good language with a mediocre toolchain. By better I mean that people will be more willing to use it, and better programs will be created. Obviously it is very hard to quantify in a non-subjective way what exactly good/average/mediocre is in terms of a language and toolchain. But roughly speaking, I think the above to be true. The only advantage that a good language with bad toolchain has over another ecosystem, is in terms of *potential*: it might be easier to improve the toolchain than to improve the language. This might be relevant if one is still an early-adopter or hobbyist, but if you want to do a real, important non-trivial project, what you care is what is the state of the toolchain and ecosystem *now*. -- Bruno Medeiros - Software Engineer
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/16 Russel Winder rus...@russel.org.uk: Definitely the case. There can only be one repository that represents the official state of a given project. That isn't really the issue in the move from CVCS systems to DVCS systems. Just note that not all projects have a specific state to represent. Many projects are centered around the concept of a centralized project, a core-team, and all-around central organisation and planning. Some projects however, I guess the Linux kernel is a prime example, have been quite de-centralized even in their nature for a long time. In the case of KDE, for a centralized example, there is a definite project version, which is the version currently blessed by the central project team. There is a centralized project planning, including meetings, setting out goals for the coming development. In the case of Linux, it's FAR less obvious. Sure, most people see master@torvalds/linux-2.6.git as THE Linux-version. However, there are many other trees interesting to track as well, such as the various distribution-trees which might incorporate many drivers not in mainline, especially for older stability-oriented kernels, RHEL or Debian is probably THE version to care about. You might also be interested in special-environment-kernels, such as non x86-kernels, in which case you're probably more interested in the central repo for that architecture, which is rarely Linuses. Also, IIRC, hard and soft realtime-enthusiasts neither looks at linuses tree first. Above all, in the Linux-kernel, there is not much of centralised planning. Linus doesn't call to a big planning-meeting quarterly to set up specific milestones for the next kernel release, but in the beginning of each cycle, he is spammed with things already developed independently, scratching someones itch. He then cherry-picks the things that has got good reviews and are interesting for where he wants to go with the kernel. That is not to say that there aren't a lot of coordination and communication, but there isn't a clear centralized authority steering development in the same ways as in many other projects. The bottom line is, many projects, even ones using DVCS, are often centrally organized. However, the Linux kernel is clear evidence it is not the only project model that works.
Re: D vs Go on reddit
2011/2/16 Bruno Medeiros brunodomedeiros+spam@com.gmail: We must not be saying (or thinking) the same thing then, because I do think it is worthwhile to have orthogonality as one of the primary design goals. I believe we are still not thinking of orthogonality in the same way. You seem to be thinking in terms of pure simplicity, how easy a language is to describe, learn and understand. I'm thinking of how much expressiveness you get per amount of complexity (how easy it is to describe, learn, and understand). So considering C++ and Java again: then yes, C++ is much more complex than Java (even new-school Java, barring generics perhaps). But I never said otherwise. I did say that Java is not more orthogonal than C++, but not in the sense that Java is just as orthogonal as C++. Rather I was trying to say that the comparison doesn't make much sense in the first place, because Java has much less capabilities. Like, you can compare D's meta-programming capabilites with C++, because in D you can do pretty much the same things as C++ (if not more) meta-programming-wise, yet the way things work in D are much more orthogonal, more simpler to describe and understand (and probably because of that, more powerful). The same comparison could be done with other features, like operator overloading between D and C++. But not between C++ and Java because doesn't support most of this functionality (and it doesn't make sense to compare with the Java alternatives) I completely agree in all of this, but I think orthogonality is a poor term for it. I think what you're describing is closer to the term elegance, in the mathematical sense (http://en.wikipedia.org/wiki/Mathematical_elegance). Mathematical elegance is basically about - Finding the simplest expression or solution for a problem, that still accounts for all possibilities. - Finding generally applicable solutions for many similar problems. (Even when the do not seem very similar. Consider, for instance physical velocity, and bitrates in computers) - Finding a solution few dependencies on other work or assumptions. It is also very close to the principle of Occams Razor, (http://en.wikipedia.org/wiki/Occam's_razor), basically saying that given two solutions to a problem which is equally correct (or equal probability of being correct), the one that is simpler is preferable. (The exact meaning of simpler is open to interpretation though. ;) A couple of good related quotes; Simplicity is the ultimate sophistication. - Da Vinci Make everything as simple as possible, but not simpler. - Einstein And finally one from Ockham himself: It is futile to do with more things that which can be done with fewer.
Re: Integer conversions too pedantic in 64-bit
On Wednesday, February 16, 2011 06:51:21 gölgeliyele wrote: On 2/16/11 9:45 AM, Steven Schveighoffer wrote: I'm done with this thread... -Steve Ok, I don't want to drag on. But there is a reason why we have a style. size_t is against the D style and obviously does not match. I use size_t as much as Walter does in my day job, and I even like it. It just does not fit into D's type names. That is all. If we were much earlier in the D development process, then perhaps it would make some sense to change the name. But as it is, it's going to break a lot of code for a simple name change. Lots of C, C++, and D programmers are fine with size_t. I see no reason to break a ton of code just because a few people complain about a name on the mailing list. Not to mention, size_t isn't exactly normal anyway. Virtually every type in D has a fixed size, but size_t is different. It's an alias whose size varies depending on the architecture you're compiling on. As such, perhaps that fact that it doesn't follow the normal naming scheme is a _good_ thing. I tend to agree with Steve on this. This is core language stuff that's been the way that it is since the beginning. Changing it is just going to break code and cause even more headaches for porting code from C or C++ to D. This definitely comes across as bikeshedding. If we were way earlier in the development process of D, then I think that there would be a much better argument. But at this point, the language spec is supposed to be essentially stable. And just because the name doesn't quite fit in with the others is _not_ a good enough reason to go and change the language spec. - Jonathan M Davis
Re: Integer conversions too pedantic in 64-bit
Am 16.02.2011 19:20, schrieb Jonathan M Davis: On Wednesday, February 16, 2011 06:51:21 gölgeliyele wrote: On 2/16/11 9:45 AM, Steven Schveighoffer wrote: I'm done with this thread... -Steve Ok, I don't want to drag on. But there is a reason why we have a style. size_t is against the D style and obviously does not match. I use size_t as much as Walter does in my day job, and I even like it. It just does not fit into D's type names. That is all. If we were much earlier in the D development process, then perhaps it would make some sense to change the name. But as it is, it's going to break a lot of code for a simple name change. Lots of C, C++, and D programmers are fine with size_t. I see no reason to break a ton of code just because a few people complain about a name on the mailing list. Not to mention, size_t isn't exactly normal anyway. Virtually every type in D has a fixed size, but size_t is different. It's an alias whose size varies depending on the architecture you're compiling on. As such, perhaps that fact that it doesn't follow the normal naming scheme is a _good_ thing. I tend to agree with Steve on this. This is core language stuff that's been the way that it is since the beginning. Changing it is just going to break code and cause even more headaches for porting code from C or C++ to D. This definitely comes across as bikeshedding. If we were way earlier in the development process of D, then I think that there would be a much better argument. But at this point, the language spec is supposed to be essentially stable. And just because the name doesn't quite fit in with the others is _not_ a good enough reason to go and change the language spec. - Jonathan M Davis Well IMHO it would be feasible to add another alias (keeping size_t), update phobos to use the new alias and to recommend to use the new alias instead of size_t. Or, even better, add a new *type* that behaves like size_t but prevents non-portable use without explicit casting, use it throughout phobos and keep size_t for compatibility reasons (and for interfacing with C). But I really don't care much.. size_t is okay for me the way it is. The best argument I've heard so far was from Michel Fortin, that having a more D-ish name may encourage the use of size_t instead of uint - but hopefully people will be more portability-aware once 64bit DMD is out anyway. IMHO it's definitely too late (for D2) to add a better type that is signed etc, like Don proposed. Also I'm not sure how well that would work when interfacing with C. It may make sense for the compiler to handle unsigned/signed comparisons and operations more strictly or more securely (= implicit casting to the next bigger unsigned type before comparing or stuff like that), though. Cheers, - Daniel
Re: What Makes A Programming Language Good
On Wednesday, February 16, 2011 09:23:04 Bruno Medeiros wrote: On 04/02/2011 20:55, bearophile wrote: Bruno Medeiros: That language ecosystems are what matter, not just the language itself. This is true, but only once your language is already very good :-) Bye, bearophile I disagree. I think an average language with an average toolchain (I'm not even considering the whole ecosystem here, just the toolchain - compilers, debuggers, IDEs, profilers, and some other tools) will be better than a good language with a mediocre toolchain. By better I mean that people will be more willing to use it, and better programs will be created. Obviously it is very hard to quantify in a non-subjective way what exactly good/average/mediocre is in terms of a language and toolchain. But roughly speaking, I think the above to be true. The only advantage that a good language with bad toolchain has over another ecosystem, is in terms of *potential*: it might be easier to improve the toolchain than to improve the language. This might be relevant if one is still an early-adopter or hobbyist, but if you want to do a real, important non-trivial project, what you care is what is the state of the toolchain and ecosystem *now*. There are people who will want a better language and will be willing to go to some effort to findand use one, bet there are plenty of programmers who just don't care. They might like to have a better language, but they're not willing to go togreat lengths to find and use one. So, even if they're presented with a fnantastic language that they might like to use, if it's a pain to use due to toolchain issues or whatnot, they won't use it. Every barrier of entry reduces the number of peoplle willing to use a particular programing language. For someone to be willing to put up/work passed a particular barrier of entry, the effort has to appear to be worthwhile to them. And often, it won't take much for a particular barrier of entry to be enough for someone to not try a language which they think _might_ be much better but don't know is much better, because they've never really used it. So, until the toolchain is reasonable to your average programmer, your average programmer isn't going to use the language. Now, by no means does that mean that the toolchain is the most important aspect of getting people to use a new language, but it _does_ mean that if you want to increase your user base, you need a solid toolchain. To get your language ironed out, you need a fair-sized user base, but there's also no point in growing the user base to large sizes long before the language is even properly usable. So, I don't know what point in the development process is the best time to really be worrying about the toolchain. As it stands, D has generally worried more about getting the language right. Now that the spec is mostly frozen, the focus is shifting towards ironing out the major bugs and fixing the major wholes in the toolchain (such as the lack of support for 64-bit and shared libraries). So, D has definitely taken the approach of trying to iron out the language before ironing out the toolchain. Regardless, it's definitely true that problems with the toolchain are preventing people from using D at this point. How good the language is if you can put up with some of its problems or how good it will be once those problems are solved is irrelevant to many programmers. They want a good toolchain _now_. And when most programmers are used to dealing with toolchains with virtually no bugs (or at least not bugs that they typically run into), they're not going to put up with one with as many bugs as D's has. We're really going to need a solid toolchain for D to truly grow its user base. And we're getting there, but it takes time. Until then though, there are a lot of programmers who won't touch D. - Jonathan M Davis
Re: Integer conversions too pedantic in 64-bit
Don wrote: [1] What was size_t on the 286 ? 16 bits Note that in the small memory model (all pointers 16 bits) it really was possible to have an object of size 0x_, because the code was in a different address space. Not really. I think the 286 had a hard limit of 16 Mb. There was a so-called huge memory model which attempted (badly) to fake a linear address space across the segmented model. It never worked very well (such as having wacky problems when an object straddled a segment boundary), and applications built with it sucked in the performance dept. I never supported it for that reason. A lot of the effort in 16 bit programming went to breaking up data structures so no individual part of it spanned more than 64K.
Re: Integer conversions too pedantic in 64-bit
Walter Bright wrote: Don wrote: [1] What was size_t on the 286 ? 16 bits Note that in the small memory model (all pointers 16 bits) it really was possible to have an object of size 0x_, because the code was in a different address space. Not really. I think the 286 had a hard limit of 16 Mb. I mean, you can have a 16 bit code pointer, and a 16 bit data pointer. So, you can concievably have a 64K data item, using the full size of size_t. That isn't possible on a modern, linear address space, because the code has to go somewhere... There was a so-called huge memory model which attempted (badly) to fake a linear address space across the segmented model. It never worked very well (such as having wacky problems when an object straddled a segment boundary), and applications built with it sucked in the performance dept. I never supported it for that reason. A lot of the effort in 16 bit programming went to breaking up data structures so no individual part of it spanned more than 64K. Yuck. I just caught the very last of that era. I wrote a couple of 16-bit DLLs. From memory, you couldn't assume the stack was in the data segment, and you got horrific memory corruption if you did. I've got no nostalgia for those days...
Re: alias this question
On 02/13/11 10:30, Olli Aalto wrote: I encountered a problem with alias this, when the aliased member is private. I'm using the latest dmd2. It reports the follwing: src\main.d(14): Error: struct K.K member s is not accessible If I change the private modifier on the s member to public it works. Is this as intended, or a bug? O. There is actually an alternative, but I believe I remember it being said that this would go away. In the meantime, I think it still works and maybe it could be saved. The alternative is to define a method opDot() which returns the entity to forward the call to. Check out std.typecons:Unique for an example. -- Chris N-S
Dynamic array initialization syntax
I have suggested a simple initialization syntax for dynamic arrays, similar to
the syntax used for fixed-sized arrays:
http://d.puremagic.com/issues/show_bug.cgi?id=5603
void main() {
auto a2 = new int[5] = void;
auto a1 = new int[5] = 1;
auto m2 = new int[][](5, 5) = void;
auto m1 = new int[][](5, 5) = 1;
}
Surely I am not the first person to suggest this :-)
Bye,
bearophile
Re: Dynamic array initialization syntax
import std.stdio;
import std.range;
auto newArray(T)(T value, size_t size)
{
return array(take(repeat(value), size));
}
void main()
{
auto a1 = newArray(5, 3);
assert(a1 == [5, 5, 5]);
}
__Dmain:; Function begin, communal
sub esp, 28 ; _ 83. EC, 1C
mov dword [esp+8H], 5 ; 0003 _ C7.
44 24, 08, 0005
mov dword [esp+4H], 1 ; 000B _ C7.
44 24, 04, 0001
mov edx, dword [esp+8H] ; 0013 _ 8B. 54 24, 08
mov eax, dword [esp+4H] ; 0017 _ 8B. 44 24, 04
pushedx ; 001B _ 52
pusheax ; 001C _ 50
call
_D3std5array72__T̔Sزange43״Take ֱֶRepeatTiZ˚ɚƆƁi; 001D _ E8,
(rel)
add esp, 28 ; 0022 _ 83. C4, 1C
xor eax, eax; 0025 _ 31. C0
ret ; 0027 _ C3
; __Dmain End of function
Is that good? I can't tell, I'm still working my way around the asm book. :)
But you did say there's an extra __memset32 call in your #2 example in
the bug issue report, and I don't see one here.
Re: Dynamic array initialization syntax
Oh, but there's a call to array. I guess that could slow things down, sorry.
Re: What Makes A Programming Language Good
Wed, 16 Feb 2011 17:23:04 +, Bruno Medeiros wrote: On 04/02/2011 20:55, bearophile wrote: Bruno Medeiros: That language ecosystems are what matter, not just the language itself. This is true, but only once your language is already very good :-) Bye, bearophile I disagree. I think an average language with an average toolchain (I'm not even considering the whole ecosystem here, just the toolchain - compilers, debuggers, IDEs, profilers, and some other tools) will be better than a good language with a mediocre toolchain. By better I mean that people will be more willing to use it, and better programs will be created. Obviously it is very hard to quantify in a non-subjective way what exactly good/average/mediocre is in terms of a language and toolchain. But roughly speaking, I think the above to be true. The only advantage that a good language with bad toolchain has over another ecosystem, is in terms of *potential*: it might be easier to improve the toolchain than to improve the language. This might be relevant if one is still an early-adopter or hobbyist, but if you want to do a real, important non-trivial project, what you care is what is the state of the toolchain and ecosystem *now*. Surprisingly this is exactly what I've been saying several times. I'd also like to point out that part of the potential for new languages comes from the fact that you can design much cleaner standard de facto libs before it takes off. Some of the issues with old languages come from the standard utilities and libraries. It sometimes takes an enormous effort to replace those. So, 100% of the potential doesn't come from redesign of the language, it's also the redesign of tools and the ecosystem. I'm also quite sure it's a redesign every time now. There are simply too many languages already to choose from. Some examples of failed designs which are still in use: PHP's stdlib with weird parameter conventions and intensive use of globals, (GNU) C/C++ build tools, Java's wasteful (in terms of heap allocation) stdlib, C++'s thread/multicore unaware runtime, C++'s metaprogramming libraries using the terrible template model, Javascript's bad parts from the era when it still was a joke. However there has been a constant flux of new languages since the 1950s. I'm sure many new languages can beat Java and C++ in several ways. But in general a new language isn't some kind of a silver bullet. Advancements in language design follow the law of diminishing returns -- even though we see complex breakthroughs in type system design, better syntax and cleaner APIs, something around 5-50% better usability/productivity/safety many times isn't worth the effort. I've seen numbers that moving from procedural programming to OOP only improved the productivity about 20-40%. Moving from OOP language 1 to OOP language 2 quite likely improves the numbers a lot less. As an example, Java's toolchain and its set of available libraries are so huge that you need millions of $$$ and thousands of man years to beat it in many domains. There simply isn't any valid technical reason not to use that tool (assuming it's the tool people typically use to get the work done). If you need a low cost web site and only php hosting is available at that price, you can't do a shit with D. Some hardcore fanboy would perhaps build a PHP backend for D, but it doesn't make any sense. It's 1000 lines of PHP vs 10 lines of D. And reclaiming the potential takes forever. It's not worth it.
Re: Integer conversions too pedantic in 64-bit
Don wrote: Walter Bright wrote: Don wrote: [1] What was size_t on the 286 ? 16 bits Note that in the small memory model (all pointers 16 bits) it really was possible to have an object of size 0x_, because the code was in a different address space. Not really. I think the 286 had a hard limit of 16 Mb. I mean, you can have a 16 bit code pointer, and a 16 bit data pointer. So, you can concievably have a 64K data item, using the full size of size_t. That isn't possible on a modern, linear address space, because the code has to go somewhere... Actually, you can have a segmented model on a 32 bit machine rather than a flat model, with separate segments for code, data, and stack. The Digital Mars DOS Extender actually does this. The advantage of it is you cannot execute data on the stack. There was a so-called huge memory model which attempted (badly) to fake a linear address space across the segmented model. It never worked very well (such as having wacky problems when an object straddled a segment boundary), and applications built with it sucked in the performance dept. I never supported it for that reason. A lot of the effort in 16 bit programming went to breaking up data structures so no individual part of it spanned more than 64K. Yuck. I just caught the very last of that era. I wrote a couple of 16-bit DLLs. From memory, you couldn't assume the stack was in the data segment, and you got horrific memory corruption if you did. I've got no nostalgia for those days... I rather enjoyed it, and the pay was good g.
Re: Integer conversions too pedantic in 64-bit
This whole conversation makes me feel like The Naive Noob for complaining about how much 32-bit address space limitations suck and we need 64 support. On 2/16/2011 8:52 PM, Walter Bright wrote: Don wrote: Walter Bright wrote: Don wrote: [1] What was size_t on the 286 ? 16 bits Note that in the small memory model (all pointers 16 bits) it really was possible to have an object of size 0x_, because the code was in a different address space. Not really. I think the 286 had a hard limit of 16 Mb. I mean, you can have a 16 bit code pointer, and a 16 bit data pointer. So, you can concievably have a 64K data item, using the full size of size_t. That isn't possible on a modern, linear address space, because the code has to go somewhere... Actually, you can have a segmented model on a 32 bit machine rather than a flat model, with separate segments for code, data, and stack. The Digital Mars DOS Extender actually does this. The advantage of it is you cannot execute data on the stack. There was a so-called huge memory model which attempted (badly) to fake a linear address space across the segmented model. It never worked very well (such as having wacky problems when an object straddled a segment boundary), and applications built with it sucked in the performance dept. I never supported it for that reason. A lot of the effort in 16 bit programming went to breaking up data structures so no individual part of it spanned more than 64K. Yuck. I just caught the very last of that era. I wrote a couple of 16-bit DLLs. From memory, you couldn't assume the stack was in the data segment, and you got horrific memory corruption if you did. I've got no nostalgia for those days... I rather enjoyed it, and the pay was good g.
Re: Integer conversions too pedantic in 64-bit
== Quote from spir (denis.s...@gmail.com)'s article On 02/16/2011 03:07 AM, Jonathan M Davis wrote: On Tuesday, February 15, 2011 15:13:33 spir wrote: On 02/15/2011 11:24 PM, Jonathan M Davis wrote: Is there some low level reason why size_t should be signed or something I'm completely missing? My personal issue with unsigned ints in general as implemented in C-like languages is that the range of non-negative signed integers is half of the range of corresponding unsigned integers (for same size). * practically: known issues, and bugs if not checked by the language * conceptually: contradicts the obvious idea that unsigned (aka naturals) is a subset of signed (aka integers) It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either. I cannot prove it, but I really think you're wrong on that. First, the question of 1 bit. Think at this -- speaking of 64 bit size: * 99.999% of all uses of unsigned fit under 2^63 * To benefit from the last bit, you must have the need to store a value 2^63 = v 2^64 * Not only this, you must step on a case where /any/ possible value for v (depending on execution data) could be = 2^63, but /all/ possible values for v are guaranteed 2^64 This can only be a very small fraction of cases where your value does not fit in 63 bits, don't you think. Has it ever happened to you (even in 32 bits)? Something like: what a luck! this value would not (always) fit in 31 bits, but (due to this constraint), I can be sure it will fit in 32 bits (always, whatever input data it depends on). In fact, n bits do the job because (1) nearly all unsigned values are very small (2) the size used at a time covers the memory range at the same time. Upon efficiency, if unsigned is not a subset of signed, then at a low level you may be forced to add checks in numerous utility routines, the kind constantly used, everywhere one type may play with the other. I'm not sure where the gain is. Upon correctness, intuitively I guess (just a wild guess indeed) if unigned values form a subset of signed ones programmers will more easily reason correctly about them. Now, I perfectly understand the sacrifice of one bit sounds like a sacrilege ;-) (*) Denis (*) But you know, when as a young guy you have coded for 8 16-bit machines, having 63 or 64... If you write low level code, it happens all the time. For example, you can copy memory areas quickly on some machines by treating them as arrays of long and copying the values -- which requires the upper bit to be preserved. Or you compute a 64 bit hash value using an algorithm that is part of some standard protocol. Oops -- requires an unsigned 64 bit number, the signed version would produce the wrong result. And since the standard expects normal behaving int64's you are stuck -- you'd have to write a little class to simulate unsigned 64 bit math. E.g. a library that computes md5 sums. Not to mention all the code that uses 64 bit numbers as bit fields where the different bits or sets of bits are really subfields of the total range of values. What you are saying is true of high level code that models real life -- if the value is someone's salary or the number of toasters they are buying from a store you are probably fine -- but a lot of low level software (ipv4 stacks, video encoders, databases, etc) are based on designs that require numbers to behave a certain way, and losing a bit is going to be a pain. I've run into this with Java, which lacks unsigned types, and once you run into a case that needs that extra bit it gets annoying right quick. Kevin
Re: Integer conversions too pedantic in 64-bit
Am 17.02.2011 05:19, schrieb Kevin Bealer: == Quote from spir (denis.s...@gmail.com)'s article On 02/16/2011 03:07 AM, Jonathan M Davis wrote: On Tuesday, February 15, 2011 15:13:33 spir wrote: On 02/15/2011 11:24 PM, Jonathan M Davis wrote: Is there some low level reason why size_t should be signed or something I'm completely missing? My personal issue with unsigned ints in general as implemented in C-like languages is that the range of non-negative signed integers is half of the range of corresponding unsigned integers (for same size). * practically: known issues, and bugs if not checked by the language * conceptually: contradicts the obvious idea that unsigned (aka naturals) is a subset of signed (aka integers) It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either. I cannot prove it, but I really think you're wrong on that. First, the question of 1 bit. Think at this -- speaking of 64 bit size: * 99.999% of all uses of unsigned fit under 2^63 * To benefit from the last bit, you must have the need to store a value 2^63 = v 2^64 * Not only this, you must step on a case where /any/ possible value for v (depending on execution data) could be = 2^63, but /all/ possible values for v are guaranteed 2^64 This can only be a very small fraction of cases where your value does not fit in 63 bits, don't you think. Has it ever happened to you (even in 32 bits)? Something like: what a luck! this value would not (always) fit in 31 bits, but (due to this constraint), I can be sure it will fit in 32 bits (always, whatever input data it depends on). In fact, n bits do the job because (1) nearly all unsigned values are very small (2) the size used at a time covers the memory range at the same time. Upon efficiency, if unsigned is not a subset of signed, then at a low level you may be forced to add checks in numerous utility routines, the kind constantly used, everywhere one type may play with the other. I'm not sure where the gain is. Upon correctness, intuitively I guess (just a wild guess indeed) if unigned values form a subset of signed ones programmers will more easily reason correctly about them. Now, I perfectly understand the sacrifice of one bit sounds like a sacrilege ;-) (*) Denis (*) But you know, when as a young guy you have coded for 8 16-bit machines, having 63 or 64... If you write low level code, it happens all the time. For example, you can copy memory areas quickly on some machines by treating them as arrays of long and copying the values -- which requires the upper bit to be preserved. Or you compute a 64 bit hash value using an algorithm that is part of some standard protocol. Oops -- requires an unsigned 64 bit number, the signed version would produce the wrong result. And since the standard expects normal behaving int64's you are stuck -- you'd have to write a little class to simulate unsigned 64 bit math. E.g. a library that computes md5 sums. Not to mention all the code that uses 64 bit numbers as bit fields where the different bits or sets of bits are really subfields of the total range of values. What you are saying is true of high level code that models real life -- if the value is someone's salary or the number of toasters they are buying from a store you are probably fine -- but a lot of low level software (ipv4 stacks, video encoders, databases, etc) are based on designs that require numbers to behave a certain way, and losing a bit is going to be a pain. I've run into this with Java, which lacks unsigned types, and once you run into a case that needs that extra bit it gets annoying right quick. Kevin It was not proposed to alter ulong (int64), but to only a size_t equivalent. ;) And I agree that not having unsigned types (like in Java) just sucks. Wasn't Java even advertised as a programming language for network stuff? Quite ridiculous without unsigned types.. Cheers, - Daniel
Re: D vs Go on reddit
Thu, 10 Feb 2011 22:38:03 +0100, Ulrik Mikaelsson wrote:
2011/2/10 Bruno Medeiros brunodomedeiros+spam@com.gmail:
I'm very much a fan of simple and orthogonal languages. But this
statement has a big problem: it's not clear what one actually considers
to be simple and orthogonal. What people consider to be orthogonal
can vary not only a little, but actually a lot. Sometimes it can
actually vary so much as to be on opposite sides. I remember seeing
that first hand here on D: two people were arguing for opposing things
in D (I don't remember the particular issue, but one was probably a
greater language change, the other as for the status quo, or a minor
change from the status quo), and explicitly argued that their
alternative was more orthogonal! I remember thinking that one was
stretching the notion of orthogonality a bit further than the other,
but I didn't find any of them to actually be incorrect.
For the sake of discussion I'll define orthogonal as non-redundant.
For instance, orthogonal dimensions in a coordinate-system is when the
dimension is completely unrelated to other dimensions, i.e. there is no
redundancy in the coordinate-system. Likewise orthogonality in a
language in my definition means it does not have redundancy in features.
Now, the problem with orthogonality is that, it is not good for
exploiting 80/20 optimisations.
Example: for most (imperative) languages, you'll somewhere have the
general way of iteration;
list x;
int i = 0;
while (i x.length) {
// do something with x[i];
i++;
}
Now, if the language is truly orthogonal, you cannot add the foreach (x
in list)-feature, since it's a redundant way of doing a subset of the
same things. Yet, it's highly likely practical thinking says that for
most programs in the language, 95% of all iteration will be
list-iteration, where the foreach-version is both shorter to write,
easier to read, and not as prone to a typo.
There is no need to guess what orthogonality means in computer science,
the definition is here http://en.wikipedia.org/wiki/
Orthogonality#Computer_science
For example if the language has both the if() statement and ? :
expression, you could rename ? : into if() else and overload the keywords
to mean both expression and a non-returning statement. Now it only has
one construct, which is more powerful than than any of the previous two.
Re: Integer conversions too pedantic in 64-bit
KennyTM~ kenn...@gmail.com wrote in message news:ijghne$ts1$1...@digitalmars.com... On Feb 16, 11 11:49, Michel Fortin wrote: On 2011-02-15 22:41:32 -0500, Nick Sabalausky a@a.a said: I like nint. But is it unsigned or signed? Do we need 'unint' too? I think 'word' 'uword' would be a better choice. I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name. 'word' may be confusing to Windows programmers because in WinAPI a 'WORD' means an unsigned 16-bit integer (aka 'ushort'). http://msdn.microsoft.com/en-us/library/cc230402(v=PROT.10).aspx That's just a legacy issue from when windows was mainly on 16-bit machines. Word means native size.
class invariants and property declarations
Hi,
I just have started diving in D. Exploring the contract feature I
stumbled upon the fact that a class invariant does not apply to properties:
import std.stdio;
void main(string[] args) {
Time t = new Time();
t.hours = 24; // works; why?
writeln(t.hours is , t.hours);
t.add(1); // triggers an assertion failure as expected
writeln(t.hours is , t.hours);
}
class Time {
invariant() {
assert( 0 = hours hours 13);
}
@property int hours;
public void add(int hours) {
this.hours += hours;
}
}
compiled using Digital Mars DMD (2.051 on Ubuntu 10.10) is given the
following result:
t.hours is 24
core.exception.AssertError@invarprop(13): Assertion failure
./InVariantProperty() [0x8057ade]
./InVariantProperty() [0x804f7e6]
./InVariantProperty() [0x804cba3]
./InVariantProperty() [0x8049856]
./InVariantProperty() [0x804fa86]
./InVariantProperty() [0x8049869]
./InVariantProperty() [0x8049813]
./InVariantProperty() [0x804f9f2]
./InVariantProperty() [0x804f94c]
./InVariantProperty() [0x804fa36]
./InVariantProperty() [0x804f94c]
./InVariantProperty() [0x804f8f4]
/lib/libc.so.6(__libc_start_main+0xe7) [0xa5cce7]
./InVariantProperty() [0x8049721]
Should not a class invariant apply to properties, too?
Kind regards
Michael
Re: class invariants and property declarations
On 16.02.2011 11:03, Michael Engelhardt wrote:
Hi,
I just have started diving in D. Exploring the contract feature I
stumbled upon the fact that a class invariant does not apply to properties:
Welcome on board :)
Invariant gets called on every public method call (at begin end if I'm
not mistaken).
Now to properties, this is actually shouldn't be allowed:
@property int hours;
@property is a annotation applied to functions (getter/setter), to allow
calling it with omitted () and a natural assign syntax like this:
class Time {
private:
int _hours;
public:
//...
@property int hours() {
return _hours;
}
@property void hours(int newHours) {
_hours = newHours;
}
}
auto t = new Time();
t.hours = 5; // calls void hours(5)
assert(t.hours == 5); //calls int hours()
Now given that setter and getter are public methods they'd got the invariant
called.
import std.stdio;
void main(string[] args) {
Time t = new Time();
t.hours = 24; // works; why?
writeln(t.hours is , t.hours);
t.add(1); // triggers an assertion failure as expected
writeln(t.hours is , t.hours);
}
class Time {
invariant() {
assert( 0= hours hours 13);
}
@property int hours;
public void add(int hours) {
this.hours += hours;
}
}
compiled using Digital Mars DMD (2.051 on Ubuntu 10.10) is given the
following result:
t.hours is 24
core.exception.AssertError@invarprop(13): Assertion failure
./InVariantProperty() [0x8057ade]
./InVariantProperty() [0x804f7e6]
./InVariantProperty() [0x804cba3]
./InVariantProperty() [0x8049856]
./InVariantProperty() [0x804fa86]
./InVariantProperty() [0x8049869]
./InVariantProperty() [0x8049813]
./InVariantProperty() [0x804f9f2]
./InVariantProperty() [0x804f94c]
./InVariantProperty() [0x804fa36]
./InVariantProperty() [0x804f94c]
./InVariantProperty() [0x804f8f4]
/lib/libc.so.6(__libc_start_main+0xe7) [0xa5cce7]
./InVariantProperty() [0x8049721]
Should not a class invariant apply to properties, too?
Kind regards
Michael
--
Dmitry Olshansky
Re: Context-Free Grammars? What about arrays?
Yes, they just happen to look identical: but that's the crux: How it looks is the *only* thing that parser/grammar are concerned with. If it worked like this: Array Decl ::= Type '[' Ident ']' Ident ';' Assoc Array Decl ::= Type '[' Ident ']' Ident ';' ...*Then* it would no longer be context-free because the parser would have to rely on the semantics of 'U' to determine how to parse it. Ahh that makes sense. Thank you for the great explanation! :)
Re: Isn't using find with retro awkward?
On 02/16/2011 07:22 AM, Denis Koroskin wrote:
On Tue, 15 Feb 2011 06:35:21 +0300, Andrej Mitrovic n...@none.none wrote:
import std.stdio, std.algorithm, std.range;
void main()
{
writeln( find([5, 1, 2, 3, 4, 5, 1], 5) );
writeln( find(retro([5, 1, 2, 3, 4, 5, 1]), 5) );
}
Output:
[5, 1, 2, 3, 4, 5, 1]
[5, 4, 3, 2, 1, 5]
The docs for find are:
returns : haystack advanced such that binaryFun!pred(haystack.front, needle)
is true
To find the last occurence of needle in haystack, call find(retro(haystack),
needle).
To me, if I was looking for the last element in a range I would expect to get
a range with the found element followed by an elements after it. Obviously
retro reverses the range (it just hard-wires front=back, back=front for those
not in the know), so this code is correct.
Still, I would expect that finding a last element in this range:
[5, 1, 2, 3, 4, 5, 1]
would return the range:
[5, 1]
and not:
[5, 4, 3, 2, 1, 5]
Isn't that what most people would want when they're looking for the last
matching element?
Try retro(find(retro(haystack, needle)));
for any reason, I would prefere
findBack(haystack, needle);
:-)
Denis
--
_
vita es estrany
spir.wikidot.com
intrinsic min and max for ints
Hello, Is there a library function for min/max for integers. I would rather not use the ?-operator, it's rather clumsy. I looked in the standard lib and only found f(min|max). Thank you, Dominic Jones
Re: intrinsic min and max for ints
Am 16.02.2011 10:54, schrieb Dominic Jones: Hello, Is there a library function for min/max for integers. I would rather not use the ?-operator, it's rather clumsy. I looked in the standard lib and only found f(min|max). Thank you, Dominic Jones They're in 'std.algorithm'. They work for all types a, b where a b is defined so also for ints. Mafi
Re: Git library for checkouts?
On 2/15/11 10:09 PM, Lars T. Kyllingstad wrote: https://github.com/schacon/libgit That'd rather be http://libgit2.github.com/, though I have no idea how usable it is already. David
regex escapes
Hello, Which characters are to be escaped: * inside [] classes * outside such classes ? Also, is there for D regexes a free form format (where whitespace can be used to present formats more legibly, but must be escaped as literals)? Denis -- _ vita es estrany spir.wikidot.com
Re: regex escapes
On 2011-02-16 5:48, spir wrote: Hello, Which characters are to be escaped: * inside [] classes * outside such classes ? Also, is there for D regexes a free form format (where whitespace can be used to present formats more legibly, but must be escaped as literals)? Denis This is a comment in a regular expression: (?#comment) The text, comment, can be replaced with anything including whitespace. The comment is terminated with ). Oh, never mind. I just tested this. std.regex doesn't support regex comments, apparently. :(
Re: Git library for checkouts?
On 2011-02-16 11:26, David Nadlinger wrote: On 2/15/11 10:09 PM, Lars T. Kyllingstad wrote: https://github.com/schacon/libgit That'd rather be http://libgit2.github.com/, though I have no idea how usable it is already. David I've seen that, but hoped for something easier to use. Was hoping for something like: git_clone(url, local_path); -- /Jacob Carlborg
Re: Git library for checkouts?
On 2011-02-15 21:32, Jacob Carlborg wrote: Maybe a little off topic but does anyone know about a git library, I'll only need to do checkouts? If it makes any difference I actually meant clone a git repository. -- /Jacob Carlborg
Re: Isn't using find with retro awkward?
On 2/16/11, spir denis.s...@gmail.com wrote: for any reason, I would prefere findBack(haystack, needle); :-) Or maybe find should have an extra parameter that decides if the search begins from the beginning or the end of the range.
Re: Isn't using find with retro awkward?
On Wed, 16 Feb 2011 11:14:27 -0500, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 2/16/11, spir denis.s...@gmail.com wrote: for any reason, I would prefere findBack(haystack, needle); :-) Or maybe find should have an extra parameter that decides if the search begins from the beginning or the end of the range. I just realized, this isn't possible in the general case. That is, given your original range [5, 1, 2, 3, 4, 5, 1], the only way to get [5, 1] is to use popFront. Think about this. What are the basic operations of a bidirectional range? popFront and popBack. There is no way to search from the back, and then use that as the front end of the resulting range. Essentially, the range API does not allow what you want unless you have a random-access range, and I don't even know if that can be generalized. The operation you are looking for is very different from what find does. -Steve
Re: Isn't using find with retro awkward?
Poor implementation, but wouldn't this work?:
import std.stdio;
import std.range;
import std.array;
auto findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
R result;
size_t index;
auto reversed = retro(haystack);
foreach (item; reversed)
{
index++;
if (item == needle)
break;
}
while (index)
{
result ~= reversed.front;
reversed.popFront;
index--;
}
return retro(result);
}
void main()
{
auto orig = [5, 1, 2, 3, 4, 5, 1];
auto result = findBack(orig, 4);
assert(array(result) == [4, 5, 1]);
}
Re: regex escapes
spir Wrote: Hello, Which characters are to be escaped: * inside [] classes * outside such classes ? Also, is there for D regexes a free form format (where whitespace can be used to present formats more legibly, but must be escaped as literals)? Though you are probably asking specifically about D: http://www.regular-expressions.info/charclass.html std.regex doesn't follow everything so testing usually must be done with D. There is no place to find what isn't supported by D. Filing bugs is of course a good choice.
Re: Isn't using find with retro awkward?
My code is a little bit broken though because if nothing is found the entire range is returned.
Re: Isn't using find with retro awkward?
Quick fix:
import std.stdio;
import std.range;
import std.array;
auto findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
R result;
size_t index;
auto reversed = retro(haystack);
bool found;
foreach (item; reversed)
{
index++;
if (item == needle)
{
found = true;
break;
}
}
if (found)
{
while (index)
{
result ~= reversed.front;
reversed.popFront;
index--;
}
}
return retro(result);
}
void main()
{
auto orig = [5, 1, 2, 3, 4, 5, 1];
auto result = findBack(orig, 4);
assert(array(result) == [4, 5, 1]);
}
Re: class invariants and property declarations
Dmitry Olshansky Wrote: Now to properties, this is actually shouldn't be allowed: @property int hours; @property is a annotation applied to functions (getter/setter), to allow calling it with omitted () and a natural assign syntax like this: Why shouldn't it be allowed? While it provides no benefit it does document that it is a property.
Re: class invariants and property declarations
On 16.02.2011 20:47, Jesse Phillips wrote: Dmitry Olshansky Wrote: Now to properties, this is actually shouldn't be allowed: @property int hours; @property is a annotation applied to functions (getter/setter), to allow calling it with omitted () and a natural assign syntax like this: Why shouldn't it be allowed? While it provides no benefit it does document that it is a property. Well, it does not affect the code in any meaningful way. Also it's not the property per see it's data member, you can even take it's address. To me such 'features' that silently do nothing should be an error. As to document anything then the comment does it and without the phantom semantic load. -- Dmitry Olshansky
Re: Isn't using find with retro awkward?
On Wed, 16 Feb 2011 12:37:04 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
Quick fix:
import std.stdio;
import std.range;
import std.array;
auto findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
R result;
size_t index;
auto reversed = retro(haystack);
bool found;
foreach (item; reversed)
{
index++;
if (item == needle)
{
found = true;
break;
}
}
if (found)
{
while (index)
{
result ~= reversed.front;
reversed.popFront;
index--;
}
}
return retro(result);
}
void main()
{
auto orig = [5, 1, 2, 3, 4, 5, 1];
auto result = findBack(orig, 4);
assert(array(result) == [4, 5, 1]);
}
Your code has a rather large design flaw. It does not return a subrange
to the original, it returns a new range. That's not in the charter of
find, find must return a portion of the original. Not to mention it
assumes R can be appended to.
For example, if I want to find the last 5 and change it to 6, I could do:
find(retro(r)).front = 6;
In your code, findBack(r).front = 6 does nothing.
-Steve
Re: Defult stack size on Windows?
On 15/02/2011 18:22, Simon wrote: On 14/02/2011 22:47, Nick Sabalausky wrote: Anyone know what DMD/OPTLINK's default stack size on windows is? Or how to find out? Dunno. Actually if you have visual studio installed you can use the dumpbin utility. the /headers switch prints out the initial stack size: 10 size of stack reserve 1000 size of stack commit Looks like dmd is defaulting to 4k. Obviously that doesn't apply to thread spawned at runtime; for windows the default is 4k again, though d-runtime might specify more or less. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: Isn't using find with retro awkward?
On 02/16/2011 05:14 PM, Andrej Mitrovic wrote: On 2/16/11, spirdenis.s...@gmail.com wrote: for any reason, I would prefere findBack(haystack, needle); :-) Or maybe find should have an extra parameter that decides if the search begins from the beginning or the end of the range. Yes, I would support this additional parameter; probably the simplest solution. (Actually had the same idea in mind, but don't remember whether I posted it :-) Denis -- _ vita es estrany spir.wikidot.com
Re: Isn't using find with retro awkward?
On 02/16/2011 05:24 PM, Steven Schveighoffer wrote: On Wed, 16 Feb 2011 11:14:27 -0500, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 2/16/11, spir denis.s...@gmail.com wrote: for any reason, I would prefere findBack(haystack, needle); :-) Or maybe find should have an extra parameter that decides if the search begins from the beginning or the end of the range. I just realized, this isn't possible in the general case. That is, given your original range [5, 1, 2, 3, 4, 5, 1], the only way to get [5, 1] is to use popFront. Think about this. What are the basic operations of a bidirectional range? popFront and popBack. There is no way to search from the back, and then use that as the front end of the resulting range. Essentially, the range API does not allow what you want unless you have a random-access range, and I don't even know if that can be generalized. The operation you are looking for is very different from what find does. Agreed. On the other hand, it is a basic operation very often provided by APIs for collections --together with several other operations having a right- or -last or version. And it's not like a trivial one-liner one would occasionnally re-implement on occasion. This is ypically, I guess, the kind of service std.algorithm is supposed to deliver. And we shouldn't find it elsewhere since this module is precisely supposed to provide general purpose algorithms. Thus, don't we face a contradiction, due to the fact that std.algorithm is mainly range-oriented? How to reconciliate this with the broader range of operations one would expect to find there? In this case, couldn't we still have the extra parameter, and check the collection allows random-access? Or have a variant with this extra param beeing non-optional and a stricter template constraint allowing only random-access ranges/collections? Denis -- _ vita es estrany spir.wikidot.com
Re: Isn't using find with retro awkward?
On 02/16/2011 06:22 PM, Andrej Mitrovic wrote:
Poor implementation, but wouldn't this work?:
import std.stdio;
import std.range;
import std.array;
auto findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
R result;
size_t index;
auto reversed = retro(haystack);
foreach (item; reversed)
{
index++;
if (item == needle)
break;
}
while (index)
{
result ~= reversed.front;
reversed.popFront;
index--;
}
return retro(result);
}
void main()
{
auto orig = [5, 1, 2, 3, 4, 5, 1];
auto result = findBack(orig, 4);
assert(array(result) == [4, 5, 1]);
}
Of course, it would work (I mean the principle, didn't test). But isn't it
stupid to (1) reconstruct the result by stepping in reversed (2) reverse twice
to finally provide a forward result ;-)
The issue I see is the typical case find in an array, a list or another kind of
sequential collection. You wouldn't do that in any case with such collections.
Don't you find it foolish algorithmically? With a list (*), you would step
backward, then just return the node/list from there; with an array, ditto and
just slice from there.
(And note in you case find(orig, 4) returns the same result ;-)
Denis
(*) If singly-linked only, there could be a need for reverse, but actually this
would rather reveal a poor choice of data structure, non matching the needs.
--
_
vita es estrany
spir.wikidot.com
Re: class invariants and property declarations
On Wednesday, February 16, 2011 09:47:32 Jesse Phillips wrote: Dmitry Olshansky Wrote: Now to properties, this is actually shouldn't be allowed: @property int hours; @property is a annotation applied to functions (getter/setter), to allow calling it with omitted () and a natural assign syntax like this: Why shouldn't it be allowed? While it provides no benefit it does document that it is a property. Except that @property is for _functions_. You mark a function with @property so that it _acts_ like a variable. @property on a variable is _meaningless_. It would be like marking a variable nothrow. It makes no sense. Neither should be legal. The fact that a member variable is public makes it a property. @property on a member variable makes no sense. - Jonathan M Davis
Re: Isn't using find with retro awkward?
On Wed, 16 Feb 2011 13:43:57 -0500, spir denis.s...@gmail.com wrote: On 02/16/2011 05:24 PM, Steven Schveighoffer wrote: On Wed, 16 Feb 2011 11:14:27 -0500, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 2/16/11, spir denis.s...@gmail.com wrote: for any reason, I would prefere findBack(haystack, needle); :-) Or maybe find should have an extra parameter that decides if the search begins from the beginning or the end of the range. I just realized, this isn't possible in the general case. That is, given your original range [5, 1, 2, 3, 4, 5, 1], the only way to get [5, 1] is to use popFront. Think about this. What are the basic operations of a bidirectional range? popFront and popBack. There is no way to search from the back, and then use that as the front end of the resulting range. Essentially, the range API does not allow what you want unless you have a random-access range, and I don't even know if that can be generalized. The operation you are looking for is very different from what find does. Agreed. On the other hand, it is a basic operation very often provided by APIs for collections --together with several other operations having a right- or -last or version. And it's not like a trivial one-liner one would occasionnally re-implement on occasion. This is ypically, I guess, the kind of service std.algorithm is supposed to deliver. And we shouldn't find it elsewhere since this module is precisely supposed to provide general purpose algorithms. Thus, don't we face a contradiction, due to the fact that std.algorithm is mainly range-oriented? How to reconciliate this with the broader range of operations one would expect to find there? In this case, couldn't we still have the extra parameter, and check the collection allows random-access? Or have a variant with this extra param beeing non-optional and a stricter template constraint allowing only random-access ranges/collections? The problem is ranges are missing some features that iterators make possible. If we think back to C++ iterators, a range is a pair of iterators. But you have the power to use whatever two iterators you want for your range. So what Andrej wants is possible in C++ (although ugly): target = std::find(std::reverse_iterator(r.end), std::reverse_iterator(r.begin), 5); target++; myrange = Range(target.base(), r.end) now the range myrange is [5, 1] one could easily abstract this into a function (e.g. rfind) so you could do: myrange = Range(rfind(r.begin, r.end), r.end); The issue is that find returns a range, and you cannot easily flip ranges given the original range. But if you get an iterator (or cursor in the case of dcollections), then constructing the correct subrange is trivial. With dcollections cursors, it's actually also safe too. -Steve
Re: class invariants and property declarations
On Wed, 16 Feb 2011 12:47:32 -0500, Jesse Phillips jessekphillip...@gmail.com wrote: Dmitry Olshansky Wrote: Now to properties, this is actually shouldn't be allowed: @property int hours; @property is a annotation applied to functions (getter/setter), to allow calling it with omitted () and a natural assign syntax like this: Why shouldn't it be allowed? While it provides no benefit it does document that it is a property. Regardless of this, you should be aware that an invariant is not called when a public field is changed/accessed, whether it's marked with @property or not. Only member functions invoke the invariant. -Steve
Re: Isn't using find with retro awkward?
The only thing I could come up with is exhausting the entire range to
get the length of a bidirectional range. But that's inefficient.
Anyway here's the dull thing:
import std.stdio;
import std.range;
import std.array;
R findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
size_t index;
bool found;
auto saved = haystack;
foreach (item; retro(haystack))
{
if (item == needle)
{
found = true;
index++;
break;
}
index++;
}
if (found)
{
size_t newIndex;
while (!haystack.empty)
{
newIndex++;
haystack.popBack;
}
newIndex -= index;
while (!saved.empty newIndex)
{
saved.popFront;
newIndex--;
}
}
return saved;
}
void main()
{
auto orig = [4, 0, 4, 0];
auto result = findBack(orig, 4);
assert(array(result) == [4, 0]);
result.front = 10;
assert(orig == [4, 0, 10, 0]);
}
You'll have to forgive me but I have yet to study algorithms properly. :)
Re: Isn't using find with retro awkward?
On Wed, 16 Feb 2011 14:24:36 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
The only thing I could come up with is exhausting the entire range to
get the length of a bidirectional range. But that's inefficient.
Anyway here's the dull thing:
import std.stdio;
import std.range;
import std.array;
R findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
size_t index;
bool found;
auto saved = haystack;
foreach (item; retro(haystack))
{
if (item == needle)
{
found = true;
index++;
break;
}
index++;
}
if (found)
{
size_t newIndex;
while (!haystack.empty)
{
newIndex++;
haystack.popBack;
}
newIndex -= index;
while (!saved.empty newIndex)
{
saved.popFront;
newIndex--;
}
}
return saved;
}
void main()
{
auto orig = [4, 0, 4, 0];
auto result = findBack(orig, 4);
assert(array(result) == [4, 0]);
result.front = 10;
assert(orig == [4, 0, 10, 0]);
}
You'll have to forgive me but I have yet to study algorithms properly. :)
Hehe if you are willing to traverse the whole range, it's much easier than
this:
auto saved = R.init;
while(!haystack.empty)
{
if(haystack.front == needle)
saved = haystack.save();
haystack.popFront();
}
return saved;
The point is, no matter what you do, the missing ability to construct a
range from two iterators/cursors means you must degrade performance to get
the desired effect.
This might be able to be simulated with having a range flip itself based
on certain criteria, but it must be a range-supported feature, which means
more complexity goes into the range concept.
-Steve
Phobos roadmap?
I've seen discussions on buffered ranges, std.parallelism, replacement of std.xml, std.process and std.stream and probably several other things I've already forgotten. DMD seems to have a quite updated roadmap in the wiki: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#Roadmap Does something like this exist for Phobos too? The page above mentions Phobos, but only that it's a moving target.
Re: Isn't using find with retro awkward?
On Wed, 16 Feb 2011 20:24:36 +0100, Andrej Mitrovic wrote:
The only thing I could come up with is exhausting the entire range to
get the length of a bidirectional range. But that's inefficient. Anyway
here's the dull thing:
import std.stdio;
import std.range;
import std.array;
R findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
size_t index;
bool found;
auto saved = haystack;
foreach (item; retro(haystack))
{
if (item == needle)
{
found = true;
index++;
break;
}
index++;
}
if (found)
{
size_t newIndex;
while (!haystack.empty)
{
newIndex++;
haystack.popBack;
}
newIndex -= index;
while (!saved.empty newIndex)
{
saved.popFront;
newIndex--;
}
}
return saved;
}
void main()
{
auto orig = [4, 0, 4, 0];
auto result = findBack(orig, 4);
assert(array(result) == [4, 0]);
result.front = 10;
assert(orig == [4, 0, 10, 0]);
}
You'll have to forgive me but I have yet to study algorithms properly.
:)
import std.stdio,std.algorithm,std.range;
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
writeln(a[a.length-1-index .. a.length]);
}
outputs:
[5,1]
but yeah, it is a little awkward.
Re: Isn't using find with retro awkward?
On 2/16/11, jam gr0v3e...@gmail.com wrote:
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
writeln(a[a.length-1-index .. a.length]);
}
That works for random-access ranges.
But I was under the impression that bidirectional ranges don't
necessarily have a length property?
Re: Isn't using find with retro awkward?
On Wednesday, February 16, 2011 13:00:13 Andrej Mitrovic wrote:
On 2/16/11, jam gr0v3e...@gmail.com wrote:
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
writeln(a[a.length-1-index .. a.length]);
}
That works for random-access ranges.
But I was under the impression that bidirectional ranges don't
necessarily have a length property?
I'm not sure. IIRC was assuming that they would and later someone pointed out a
valid case where they wouldn't. So, in the long run, they probably won't but
they may right now.
Actually, I'll check... No. They don't require a range. They must be a forward
range and then have popBack and back in addition, but length is not required.
- Jonathan M Davis
Re: Phobos roadmap?
On Wednesday, February 16, 2011 12:13:59 simendsjo wrote: I've seen discussions on buffered ranges, std.parallelism, replacement of std.xml, std.process and std.stream and probably several other things I've already forgotten. DMD seems to have a quite updated roadmap in the wiki: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#Roadmap Does something like this exist for Phobos too? The page above mentions Phobos, but only that it's a moving target. There is no Phobos roadmap at this point. It's all very adhoc at this point. There are plans for stuff to be replaced or added, and some if it is partway along, but for the most part at this point, something makes it into Phobos whenever it's ready. Most of what happens gets done because someone wants it to get done and takes the time to get it done. We're moving towards a more formalised review process, but even that depends on when someone has something ready for review. We really should better document what's intended to be replaced and possibly even what we expect to have done soon, but for the most part at this point, what you see is what you get. If you pay attention to the D and Phobos newsgroups, then you have a better idea of what's coming, but even then, it's not entirely clear. There's definitely no roadmap though. - Jonathan M Davis
Re: Isn't using find with retro awkward?
On Wednesday, February 16, 2011 13:36:54 Jonathan M Davis wrote:
On Wednesday, February 16, 2011 13:00:13 Andrej Mitrovic wrote:
On 2/16/11, jam gr0v3e...@gmail.com wrote:
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
writeln(a[a.length-1-index .. a.length]);
}
That works for random-access ranges.
But I was under the impression that bidirectional ranges don't
necessarily have a length property?
I'm not sure. IIRC was assuming that they would and later someone pointed
out a valid case where they wouldn't. So, in the long run, they probably
won't but they may right now.
Actually, I'll check... No. They don't require a range. They must be a
forward range and then have popBack and back in addition, but length is
not required.
Yikes. I should re-read my posts more. I meant to so that IIRC, Andrei was
assuming that they would.
However, regardless of what was assumed before, bidirectional ranges do _not_
have to a length property.
- Jonathan M Davis
Re: Isn't using find with retro awkward?
On 02/16/2011 09:42 PM, jam wrote:
On Wed, 16 Feb 2011 20:24:36 +0100, Andrej Mitrovic wrote:
The only thing I could come up with is exhausting the entire range to
get the length of a bidirectional range. But that's inefficient. Anyway
here's the dull thing:
import std.stdio;
import std.range;
import std.array;
R findBack(alias pred = a == b, R, E)(R haystack, E needle)
if (isBidirectionalRange!R)
{
size_t index;
bool found;
auto saved = haystack;
foreach (item; retro(haystack))
{
if (item == needle)
{
found = true;
index++;
break;
}
index++;
}
if (found)
{
size_t newIndex;
while (!haystack.empty)
{
newIndex++;
haystack.popBack;
}
newIndex -= index;
while (!saved.empty newIndex)
{
saved.popFront;
newIndex--;
}
}
return saved;
}
void main()
{
auto orig = [4, 0, 4, 0];
auto result = findBack(orig, 4);
assert(array(result) == [4, 0]);
result.front = 10;
assert(orig == [4, 0, 10, 0]);
}
You'll have to forgive me but I have yet to study algorithms properly.
:)
import std.stdio,std.algorithm,std.range;
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
writeln(a[a.length-1-index .. a.length]);
}
outputs:
[5,1]
but yeah, it is a little awkward.
And you're assuming the range is slice-able (I mean at arbitrary position,
witout popping it); which you cannot do in the general case.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Isn't using find with retro awkward?
On Wed, 16 Feb 2011 22:00:13 +0100, Andrej Mitrovic wrote:
On 2/16/11, jam gr0v3e...@gmail.com wrote:
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
writeln(a[a.length-1-index .. a.length]);
}
That works for random-access ranges.
But I was under the impression that bidirectional ranges don't
necessarily have a length property?
Doh. That is exactly correct. I guess the following would work for
bidirectional ranges:
import std.stdio,std.algorithm,std.range,std.container;
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
auto R = retro(take(retro(a),index+1));
writeln(R);
R[0] = 6;
writeln(a);
}
but this is just getting nutty.
Re: Isn't using find with retro awkward?
On 2/16/11, jam gr0v3e...@gmail.com wrote:
import std.stdio,std.algorithm,std.range,std.container;
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
auto R = retro(take(retro(a),index+1));
writeln(R);
R[0] = 6;
writeln(a);
}
but this is just getting nutty.
Nutty, but it's great how much lines you can save when composing
ranges. retro and take are both lazy afaik, so this can't be that bad?
Re: Isn't using find with retro awkward?
On Thu, 17 Feb 2011 00:05:15 +0100, Andrej Mitrovic wrote:
On 2/16/11, jam gr0v3e...@gmail.com wrote:
import std.stdio,std.algorithm,std.range,std.container;
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
auto R = retro(take(retro(a),index+1)); writeln(R);
R[0] = 6;
writeln(a);
}
but this is just getting nutty.
Nutty, but it's great how much lines you can save when composing ranges.
retro and take are both lazy afaik, so this can't be that bad?
Well take is for sure, but I'm not sure about retro(I didn't see anything
in range.d or the online docs that indicate it is). You could save some
work by just reversing the container once at the start though.
Re: Isn't using find with retro awkward?
On Wednesday, February 16, 2011 15:19:01 jam wrote:
On Thu, 17 Feb 2011 00:05:15 +0100, Andrej Mitrovic wrote:
On 2/16/11, jam gr0v3e...@gmail.com wrote:
import std.stdio,std.algorithm,std.range,std.container;
void main()
{
auto a = [5,1,2,3,4,5,1];
auto index = countUntil(retro(a),5);
auto R = retro(take(retro(a),index+1)); writeln(R);
R[0] = 6;
writeln(a);
}
but this is just getting nutty.
Nutty, but it's great how much lines you can save when composing ranges.
retro and take are both lazy afaik, so this can't be that bad?
Well take is for sure, but I'm not sure about retro(I didn't see anything
in range.d or the online docs that indicate it is). You could save some
work by just reversing the container once at the start though.
All retro does is forward front and popFront to back and popBack and back and
popBack to front and popFront. So, the only overhead is the extra function
call,
which is probably inlined anyway.
- Jonathan M Davis
Re: Double-dispatch
On 13/02/11 9:32 PM, Sean Eskapp wrote: == Quote from bearophile (bearophileh...@lycos.com)'s article Sean Eskapp: Is there a nicer way to do this in D, or am I stuck with the same thing? Andrei has recently said no one needs double dispatch (in D) :-) So Andrei will be interested in your use case. Bye, bearophile The age-old collision handling problem is how I'm using it. Use a 2D array of function pointers, with the indices coming from unique IDs on the shapes.
[Issue 5580] [64-bit] String switch statements broken in 64-bit mode
http://d.puremagic.com/issues/show_bug.cgi?id=5580 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2011-02-16 00:54:02 PST --- https://github.com/D-Programming-Language/dmd/commit/f1c158eac6f9d1a28314c7e473c89be8b8a4f774 https://github.com/D-Programming-Language/dmd/commit/b3bb64d6ff00beddfc45c228941feedeb2e27842 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5593] Add dladdr to druntime for linux/FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=5593 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #2 from Iain Buclaw ibuc...@ubuntu.com 2011-02-16 05:18:22 PST --- It's not a Posix standard as far as I'm aware, but it was first defined in SunOS, and all others followed suit. http://www.unix.com/man-page/OpenSolaris/3c/dladdr/ http://www.unix.com/man-page/Linux/3/dladdr/ http://www.unix.com/man-page/FreeBSD/3/dladdr/ http://www.unix.com/man-page/OSX/3/dladdr/ Regards -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5451] Three ideas for RedBlackTree
http://d.puremagic.com/issues/show_bug.cgi?id=5451 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2011-02-16 06:20:45 PST --- *** Issue 5586 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5594] New: MODEL doesn't work the same way for DMD, Phobos and Druntime
http://d.puremagic.com/issues/show_bug.cgi?id=5594 Summary: MODEL doesn't work the same way for DMD, Phobos and Druntime Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha dsim...@yahoo.com 2011-02-16 06:57:23 PST --- To build DMD as a 64-bit binary: make -flinux.mak MODEL=-m64 To build Phobos or Druntime as 64-bit: make -fposix.mak MODEL=64 These are not consistent and should be. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5596] New: SortedRange regression
http://d.puremagic.com/issues/show_bug.cgi?id=5596
Summary: SortedRange regression
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2011-02-16 07:46:16 PST ---
The following code works on 2.051 but not 2.052 beta:
import std.range, std.algorithm, std.functional;
alias SortedRange!(string[], a b) Set;
Set readTfList(string setFile) {
string[] raw;
return pipe!(sort, uniq, array, assumeSorted)(raw);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5596] SortedRange regression
http://d.puremagic.com/issues/show_bug.cgi?id=5596 --- Comment #1 from David Simcha dsim...@yahoo.com 2011-02-16 07:46:57 PST --- Forgot to paste in the error message. Here it is: d:\dmd2\windows\bin\..\..\src\phobos\std\range.d(5415): Error: this for _input needs to be type SortedRange not type SortedRange!(string[],a b) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5595] Compiler crash on heavy std.algorithm use
http://d.puremagic.com/issues/show_bug.cgi?id=5595 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2011-02-16 07:58:26 PST --- Confirmed. I'm on it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5597] New: [64-bit] Illegal Instruction on Ancient Hardware
http://d.puremagic.com/issues/show_bug.cgi?id=5597
Summary: [64-bit] Illegal Instruction on Ancient Hardware
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2011-02-16 08:17:59 PST ---
The following code works on newer hardware, but terminates with Illegal
instruction on some ancient CPUs (details below):
import std.conv;
void main() {
string foo = 1.0;
parse!float(foo);
}
The ancient hardware in question (first CPU from cat /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name :Intel(R) Xeon(TM) MP CPU 3.66GHz
stepping: 1
cpu MHz : 3657.816
cache size : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor
ds_cpl est tm2 cid cx16 xtpr
bogomips: 7321.85
clflush size: 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5401] std.socket updates and boost license
http://d.puremagic.com/issues/show_bug.cgi?id=5401 Masahiro Nakagawa repeate...@gmail.com changed: What|Removed |Added CC||repeate...@gmail.com --- Comment #5 from Masahiro Nakagawa repeate...@gmail.com 2011-02-16 08:27:57 PST --- http://lists.puremagic.com/pipermail/phobos/2010-July/001171.html I suggested std.socket replacement in Phobos ML. This improvement that creates Asio based new socket is still continuing with a view to event, but I don't have enough time ;( -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5595] Compiler crash on heavy std.algorithm use
http://d.puremagic.com/issues/show_bug.cgi?id=5595
--- Comment #2 from Don clugd...@yahoo.com.au 2011-02-16 08:28:43 PST ---
The regression was caused by a Phobos change, which has triggered a compiler
segfault in interpret.c.
In attempting to instantiate map!(to), 'to' is a symbol with no identifier.
(.ident is NULL).
The segfault can be prevented in dsymbol.c, line 70, by checking for a null
identifier. But without knowing why we're getting a null identifier, I can't
recommend this as a valid patch.
int Dsymbol::equals(Object *o)
{ Dsymbol *s;
if (this == o)
return TRUE;
s = (Dsymbol *)(o);
-if (s ident-equals(s-ident))
+if (s s-ident ident-equals(s-ident))
return TRUE;
return FALSE;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
