Re: another d demoscene entry
Same for me. It just crashes while loading. The debug version is more informative. It says: Error: CompileError : Cannot compile data/shaders/glow.fs LOG : (1) : error C5018: length of constructed vectors cannot exceed 4 These three lines are not in log.txt, but everything else is. The log.txt is attached. Hey, thanks :) ! Indeed there is an error. uniform sampler1D tex; gl_FragColor = gl_Color * vec4(1.0,1.0,1.0, texture1D(tex, a)); should be replaced by: gl_FragColor = gl_Color * vec4(1.0,1.0,1.0, texture1D(tex, a).x);
Re: Revamping associative arrays
Andrei Alexandrescu: I like how you leave no stone unturned. Regardless of what the final quality of the D2 language will be, I will always think you have done your best to improve it. I will say so to the people I know too. I have already discussed about D AAs in the past, but I guess it was not the right moment to do. Do we want to keep them in the language? It's easy to do an: import std.collections: HashMap; And a flexible language is supposed to allow for a handy syntax even for user-defined collections. But the built-ins have a nicer syntax and a little different purpose. So I think having the built-in syntax is good. That syntax may map to built-in logic, or to library code. Both options are acceptable, but I think having built-in logic is a little better. But I need templated HashMaps and TreeMaps too in a std.collections. Using templates leads to faster code, so the hash in collections can be templated. But templates slow down compilation and inflate binary size. Built-i AAs have a handy syntax, so they get used more often, even where you put only 6 items into them. So I'd like built-in AAs to be optimized for a very small number of items too. There are several ways to do this. Built-in AAs must be the most general and very flexible, easy to use, and not bug-prone. I don't need built-in AAs to be the faster ones, or the ones the use the less memory. This is an optimization, so for such more demanding needs I can use the HashMap from the collections module. So a good thing of built-in AAs is that they don't inflate code a lot, and the compilation is fast, so they can be used everywhere in the program performance in both speed and memory isn't critical (and this happens). I like how the current AA design never degenerate to an O(n^2) behaviour (Python dicts are much faster than the current D AAs but Python dicts in corner cases go quadratic). But this quality has the disadvantage of requiring a opCmp too to items that I want to put in an AA (because final chaining is resolved with an ordered tree), while in Python and other languages I need just an opEq and an opHash. Regarding the iteration, I'd like the design used in Python3, where keys and values (and items, that are pairs, if you want) return a small iterable object that's a view to the dict. I may also want methods that return a true array of values/items/keys as now, because once in a while you need this too (Python3 doesn't have this, and you need to do list(d.keys())). The keys() returns an light immutable set object, this is very good and very handy. Doing set operations is a godsend in certain kinds of code. To delete an key-value another possible syntax is: delete d[key] But d.delete(key) too is acceptable. LDC compiler is able to optimize away the double lookups if they are done nearby, so it's even possible for the in to return a boolean. (But I like to have both !in and !is too). I don't use .rehash often, and it takes some time to run. So I don't know how much useful it is. I need a .clear method too. And maybe a .copy too. AAs *must* support opEqual too, as in LDC, because I have to know when a function returns the correct AA inside unittests. (Python dicts even support opCmp, but this is a little tricky, and less useful, so this can be omitted). This features don't require 100 lines of code, but they make AAs quite more useful and handy. A method like Python .get(key[, default]) is quite useful, it returns default if the key is missing. In D probably the default can't be optional. fromkeys, update (and maybe pop and popitem too) methods can be useful, see Python docs: http://docs.python.org/library/stdtypes.html#dict .update can also be written as ~, but there it works only with another AA, and it's not commutative. I'd like to have a literal for an empty AA, I use AA!(K,V) in my dlibs. An old idea: If the value of an AA is of type void, the AA may not allocate memory for them, so the AA becomes a set (and it needs few basic set operations, with operator overload). I may like an AA to be false when empty. I'd like to have a standard way to, given a pointer to a AA value, return its key. I have a function that does this in my dlibs (module extra) but it's not officially, so it will break when the AA implementation will change. This is useful if I want to implement a richer data structure on top of built-in AAs, for example an ordered AA that when iterated on, yields items in the same order as the insertion order, so values are kept linked in a double linked list, to do this and keep the data structure flexible I need to know a key given a pointer to a value. I may like a freeze method that turns an AA into an immutable one. Ruby has this. A .reserve method may be useful to speed up AA creation when you know you have to add tons of pairs. I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key
Re: Communicating between in and out contracts
Andrei Alexandrescu wrote: Rainer Deyke wrote: The expression may mutate stuff. It shouldn't. It's an error if it does, just like it's an error for an assertion or post/precondition to have any side effects. It would be nice if the compiler could catch this error, but failing that, 'old' expressions are still no worse than assertions in this respect. If you know about Eiffel's old, I'd appreciate if you explained how it works. I am arguing exactly because I don't know. My understanding is that neither of us currently knows how it works, so I don't think it's ok to refer me to Eiffel. My suggestion to ask the Eiffel community directly was meant seriously. -- Rainer Deyke - rain...@eldwood.com
Re: Revamping associative arrays
language_fan wrote: It would be great if the underlying implementation could be switched based on the task at hand. The AAs could be completely library provided, with only a small built-in syntactical sugaring on top of it. They already are. In D1, the complete implementation is in phobos/internal/aaA.d, and the compiler knows nothing about it other than the function signatures.
Re: Revamping associative arrays
On Sat, 17 Oct 2009 22:47:21 +0200, grauzone n...@example.net wrote: Max Samukha wrote: On Sat, 17 Oct 2009 13:28:51 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Associative arrays are today quite problematic because they don't offer any true iteration. Furthermore, the .keys and .values properties create new arrays, which is wasteful. Another issue with associative arrays is that ++a[k] is hacked, which reflects a grave language limitation. That needs to be replaced with a true facility. Any other issues with AAs that you want to see fixed, and ideas guiding a redesign? Thanks, Andrei They should be true reference types. Now we have oddities like this: int[int] a; auto b = a; a[1] = 2; assert(b[1] == 2); // Range violation int[int] a; a[1] = 2; auto b = a; a[2] = 3; assert(b[2] == 3); // Ok That's because the actual AA is allocated on demand (when you add the first element). The new array type T[new] is going to have the same problem. I agree. But the problem is the lack of a decent way to instantiate an empty AA. Now you either have to do idiotic things like: int[int] a; a[1] = 1; a.remove(1); Or wrap the array in another type. And, talking about T[new], we should be able to instantiate them eagerly as well. I like it, because if you don't need it, it doesn't allocate memory. Of course it's possible that the complication in semantics isn't it worth. But D is still a systems programming language with a *very* bad GC, which is why I think it should continue to work this way.
Re: Revamping associative arrays
Walter Bright: You can iterate over both keys and values with: foreach (key, value; aa) I know this, of course, but you are missing the point by a mile. An explicit foreach is not the only way you may want to iterate an AA on. If I have a higher order function like map, I must be able to use it on any kind of iterable. Like an array, associative array, a set, a list, and so on. I must be able to change the data structure I give to the map, if the need arise while I change the code, and it has to keep working. If the mapping function takes a single argument the map has to choose to what iterate, among keys or values (or even both, as pairs). In such case iterating on keys is more useful. That's how all my dlibs higher order functions work when you give them an AA, they iterate on AA keys, array items, set items, list items, etc. If you think still I am not right, you may ask for a poll here, to see how many like the default AA iteration to be on keys or values. Bye, bearophile
Re: Revamping associative arrays
Max Samukha:
I agree. But the problem is the lack of a decent way to instantiate an
empty AA. Now you either have to do idiotic things like:
int[int] a;
a[1] = 1;
a.remove(1);
Or wrap the array in another type.
This is an empty AA, you need nothing else:
int[int] a;
In my post I have also said I'd like to have a built-in expression literal for
empty AA, I use this in my dlibs:
private template AA_impl(KeyType, ValueType) {
ValueType[KeyType] result;
const ValueType[KeyType] res = result;
}
template AA(KeyType, ValueType) {
const ValueType[KeyType] AA = AA_impl!(KeyType, ValueType).res;
}
That you can use for example like this, to give an empty AA to a foo() function:
foo(AA!(int, float));
Something built-in with a better syntax may be found, example:
That can be used like:
foo([int:float]);
Bye,
bearophile
Re: Revamping associative arrays
bearophile: That you can use for example like this, to give an empty AA to a foo() function: foo(AA!(int, float)); I have just found that you can also use null there. It's less explicit because if you take a look at the call site only, you don't know that the receiver will need an AA. That's why I'd like to disallow null to be used where an empty array can be given (and force the programmer to use [] there). This is also how Delight language works. Bye, bearophile
Re: Revamping associative arrays
bearophile Wrote: I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key I can find its value, while the opposite is not possible, so having keys is much more useful. This is true in Python too. In my dlibs all iterables and functions behave like this. The current D design is just a design mistake ad Walter was wrong on this. No! No! No! Maybe you are wrong. Or it's a metter of taste. I remember that I spent many hours on finding bug in python's script written by me in my job. The reason was the python's behaviour decribed by you. Then I couldn't understand why the hell iterating on collection returns a key in the first place. It's so not intuitive. Your explanation is not even close in convincing me. If I wanted keys I would write: foreach (key, value; set) or (key; set.keys) Now I know why I don't like Python and I hope I will never have to need it again. For scriptng (but not at work since I don't do scripting enymore) I prefer D (rdmd). bearophile, I like your great commitment in D development but I don't like pushing D toward pythonish world. (Of course some ideas from Python project could be succesfully used in D) Cheers Piotrek
Re: dmd support for IDEs and the D tool chain
Eric Suen wrote: Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, Doing this would make it more difficult than necessary to move D to new platforms, and would make it more difficult than necessary to adapt it to other back ends which are usually implemented in C or C++. Does Walter Bright use D for any projects himself? dmdscript, Empire, Microemacs, and any new utilities I write, such as the D archives generator.
Re: Revamping associative arrays
On Sun, 18 Oct 2009 04:29:57 -0400, bearophile bearophileh...@lycos.com wrote: Max Samukha: I agree. But the problem is the lack of a decent way to instantiate an empty AA. Now you either have to do idiotic things like: int[int] a; a[1] = 1; a.remove(1); Or wrap the array in another type. This is an empty AA, you need nothing else: int[int] a; I showed in my original post it is not enough to use AA as a reference type.
execute file size is much big from dmd1041.
I use bud build the dwt.lib. then use dmd -L+dwt.lib build the execute file. it is much fast then other ways. the problem is , the execute file size is become very big since dmd 1.41 . I try dwt-win and dwt Shawn Liu , the execute file size is both grow big. I try dmd 1.035 to dmd 1.041, the execute file size is similar, build Snippet38 the size is 850kb. I try dmd 1.041 to dmd1050 and dmd r215, the file size is 1.7M¡£ my os is Window XP. I use bud all.d -clean -full -allobj -ofdwt -release -O -I../ -lib to build dwt.lib. I use dmd1040 Snippet38.d -IE:\dmd\gui\dwt1 -L+advapi32_dwt.lib+gdi32_dwt.lib+comctl32_dwt.lib+comdlg32.lib+imm32_dwt.lib+kernel32_dwt.lib+msimg32_dwt.lib+ole32_dwt.lib+oleacc_dwt.lib+oleaut32_dwt.lib+olepro32_dwt.lib+shell32_dwt.lib+user32_dwt.lib+usp10_dwt.lib+version_dwt.lib+uuid.lib+dwt.lib -L/SUBSYSTEM:windows:4 to build Snippet38 . I spent a lot of time on this issue, and please help me. sorry for my poor english.
Re: 64-bit
Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote: I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients do not share this view for a series of good reasons. Even their older systems tend to be 64-bit nowadays. Migration towards 64-bit OSes is under way. There is still 32-bit compatibility if needed. At the same time certain programs will perform drastically better when compiled to 64-bit. Replacement thus can be postponed which is usually the best way to keep CFOs happy. 64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task.
Re: Revamping associative arrays
bearophile wrote: Andrei Alexandrescu: I like how you leave no stone unturned. Regardless of what the final quality of the D2 language will be, I will always think you have done your best to improve it. I will say so to the people I know too. Well it should be said Walter is doing his best too, I'm just bitching more :o). I have already discussed about D AAs in the past, but I guess it was not the right moment to do. My thoughts are aligned to yours. I'm not sure whether much or any of this is attainable within D2. Andrei
Error: long has no effect in expression (0)
I use dmd 1.049 , dmd 1.050, dmd r215 to build dwt-win static lib. dmd @AllFiles.txt -d -ofdwt.lib -lib -op -JE:\dmd\gui\res there is a error throw out by dmd: internal\ole\win32\COM.d(378): Error: long has no effect in expression (0) it repeat 5 times. the problem is , the line content is only a const : public static const int S_OK = 0 ; , I don't know where is wrong. please hlep me.
Re: execute file size is much big from dmd1041.
dwt_test дµ½: I use bud build the dwt.lib. then use dmd -L+dwt.lib build the execute file. it is much fast then other ways. the problem is , the execute file size is become very big since dmd 1.41 . I try dwt-win and dwt Shawn Liu , the execute file size is both grow big. I try dmd 1.035 to dmd 1.041, the execute file size is similar, build Snippet38 the size is 850kb. I try dmd 1.041 to dmd1050 and dmd r215, the file size is 1.7M¡£ my os is Window XP. I use bud all.d -clean -full -allobj -ofdwt -release -O -I../ -lib to build dwt.lib. I use dmd1040 Snippet38.d -IE:\dmd\gui\dwt1 -L+advapi32_dwt.lib+gdi32_dwt.lib+comctl32_dwt.lib+comdlg32.lib+imm32_dwt.lib+kernel32_dwt.lib+msimg32_dwt.lib+ole32_dwt.lib+oleacc_dwt.lib+oleaut32_dwt.lib+olepro32_dwt.lib+shell32_dwt.lib+user32_dwt.lib+usp10_dwt.lib+version_dwt.lib+uuid.lib+dwt.lib -L/SUBSYSTEM:windows:4 to build Snippet38 . I spent a lot of time on this issue, and please help me. sorry for my poor english. I thing it is introduce by http://d.puremagic.com/issues/show_bug.cgi?id=2673 . the dmd may be link all module in lib, it should only link module that has a static this.
Re: Revamping associative arrays
Piotrek: No! No! No! Maybe you are wrong. Life is complex so I am usually wrong, because it's hard to consider all sides of a thing, but sometimes other people are even more wrong :-) I remember that I spent many hours on finding bug in python's script written by me in my job. The reason was the python's behaviour decribed by you. I have have followed many Python programmers for a lot of time and I think such problem of yours is not common. But I'll keep an eye open for possible other people with your problem. Then I couldn't understand why the hell iterating on collection returns a key in the first place. It's so not intuitive. What's intuitive on iterating on values? Well, I think Walter agrees with you, I remember his explanation (iterating on a normal array doesn't yield its indexes), but beside what's intuitive you have also to keep in mind what's handy, and iterating on keys is more useful. Beside the things I have said, if you think of associative arrays as sets where there is a value associated to each set item (and this is how Python dicts are implemented and how the light iterable objects they give you when you ask for keys in Python3), when you iterate on the set you get the set items, so if you extend the set you keep iterating on the set items... Your explanation is not even close in convincing me. If I wanted keys I would write: foreach (key, value; set) or (key; set.keys) In D set.keys needs a good amount of memory and time, it's useful only in special situations, for example when you are sure your AA is small. Andrei will probably push to add/replace something to find keys and a lazy way. Now I know why I don't like Python and I hope I will never have to need it again. For scriptng (but not at work since I don't do scripting enymore) I prefer D (rdmd). Refusing forever to use a popular (and usually quite appreciated) language just because you don't like a single small feature is stupid. I don't want to force you to like Python, but the choice of a language must be based on a bit more global evaluation of it. Every language under the sun has plenty warts. C++ has enough warts (far larger than the one you have listed) that you can write a big book on them, but people keep using it still. Not doing scripting any more too is probably a not smart thing to say, because in most programming jobs I've seen, there are small files to munge, commands to automate, things to show or plot, and so on, etc. A scripting language (even just shell scripting) is designed for such things. bearophile, I like your great commitment in D development but I don't like pushing D toward pythonish world. (Of course some ideas from Python project could be succesfully used in D) Thank you :-) I've known several languages (I think this is normal in this newsgroup), and I try to suggest what my experience shows me :-) I'm often wrong anyway. Bye, bearophile
Re: 64-bit
On 2009-10-18 11:32:07 +0200, language_fan f...@bar.com.invalid said: Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote: I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients do not share this view for a series of good reasons. Even their older systems tend to be 64-bit nowadays. Migration towards 64-bit OSes is under way. There is still 32-bit compatibility if needed. At the same time certain programs will perform drastically better when compiled to 64-bit. Replacement thus can be postponed which is usually the best way to keep CFOs happy. 64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task. on x86 the 64 bit extension added registers, that makes it faster, even if as you correctly point out a priori just using 64 bit pointers is just a drawback unless you have lot of memory. Anyway I also need 64 bit (computational chemistry, speed and memory hungry), and to that the only thing that I can say is D1 works very well with 64 bit. Fawzi
Re: Revamping associative arrays
Sun, 18 Oct 2009 06:18:34 -0400, bearophile wrote: Then I couldn't understand why the hell iterating on collection returns a key in the first place. It's so not intuitive. What's intuitive on iterating on values? Well, I think Walter agrees with you, I remember his explanation (iterating on a normal array doesn't yield its indexes), but beside what's intuitive you have also to keep in mind what's handy, and iterating on keys is more useful. It's easy to see what's intuitive if you consider what a collection contains. To me, it contains *values*, always. These values may be indexed: by an arbitrary key (AA), by an integral index (array), or not at all (single-linked list). But the index is not the point, it's only a way to access values. And when I iterate over a collection, I definitely wan to iterate over the values it contains, regardless of an indexing scheme this particular collection uses.
Re: Revamping associative arrays
Andrei Alexandrescu: I'm not sure whether much or any of this is attainable within D2. The things I've written about aren't all equally important and they don't require the same amount of work to be implemented. I am sorry for writing that gazpacho. There are two things that I think are more important that can implemented now: the opEquals among AAs, and the default iteration with foreach on the keys. The other things can wait. The opEquals among AAs requires probably less than 20 lines of code. Two persons (plus Walter, of course) have said they don't like to iterate on the keys first. The other people have kept muzzle shut so I can't tell yet. Bye, bearophile
Re: 64-bit
Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote: On 2009-10-18 11:32:07 +0200, language_fan f...@bar.com.invalid said: Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote: I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients do not share this view for a series of good reasons. Even their older systems tend to be 64-bit nowadays. Migration towards 64-bit OSes is under way. There is still 32-bit compatibility if needed. At the same time certain programs will perform drastically better when compiled to 64-bit. Replacement thus can be postponed which is usually the best way to keep CFOs happy. 64-bit programs often also require larger CPU caches to work efficiently, more disk space (larger binaries), and finally larger memory consumption. 32-bit x86 + PAE still works until you have more than 64 GB of RAM or processes larger than 2 or 3 GB. So, in desktop use 32-bit feels like the best way to go unless 64-bit algorithms are provably more efficient in the chosen task. on x86 the 64 bit extension added registers, that makes it faster, even if as you correctly point out a priori just using 64 bit pointers is just a drawback unless you have lot of memory. That is very silly claim. First, you need to have use for all those extra registers to obtain any performance benefits. This is nearly not always the case. Also note that cache size is heavily constrained and larger binaries will fill it with less code. This alone can make the code a lot slower on first generation and budget 2..4-core x86 machines with smaller cache sizes. Main memory is expensive and you rarely can install more than 64 GB on a PC style hardware. Many times you can even split a task into separate 2..3 GB processes quite easily. So the immediate advantages of 64-bit code are not that clear when you only need it to grow the processes larger. On Linux, for instance, ordinary 64-bit desktop requires a lot more memory than its 32-bit alternative. Why would you want to buy more hardware to fix something that can be fixed with existing software? Anyway I also need 64 bit (computational chemistry, speed and memory hungry), and to that the only thing that I can say is D1 works very well with 64 bit. That's one domain where 64 bits may give you an advantage. In normal desktop applications there is often nothing in 64-bit code that can improve anything. I am talking about firefox / winamp / mediaplayer / photoshop / outlook / casual gaming use here. Why I mentioned desktop applications is that currently the trend has been to replace old 32-bit intel/amd processors in desktop use. And most desktop apps are written in systems programming languages. You can hardly buy any non-64-bit capable processor from any pc store these days. The people are getting crap that they don't need. The same thing happens with digital cameras. In cameras the pixel count of sensors is growing even though the image quality stays the same. A good quality 4 MPix camera is much better than a cheap 15 MPix pocket camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored in jpg format might look better than the original 15 MPix one in raw format. They just keep pushing the limits to sell larger and larger storage media.
Re: Revamping associative arrays
On Sun, Oct 18, 2009 at 10:56 AM, bearophile bearophileh...@lycos.com wrote:
The opEquals among AAs requires probably less than 20 lines of code.
Two persons (plus Walter, of course) have said they don't like to iterate on
the keys first. The other people have kept muzzle shut so I can't tell yet.
I typed a long post that weighed lots of pros and cons of different
options, but then I hit upon a simple rule that I think makes a lot of
sense:
I think the default should be to iterate over whatever 'in' looks at.
And conversely, I think 'in' should compare against whatever default
iteration iterates over.
Proposed:
arrays -- default iteration over values, x in A answers if x is
one of the values.
assoc arrays -- default iteration over keys, x in AA answers if x
is one of the keys
sets -- iteration over keys (or call 'em values, could be either), x
in S answers if x is one of them
I think this is what Python uses, actually. But I just think it makes
a lot of sense to say that 'x in Y' should be some kind of shorthand
for
foreach(thing; Y) {
if (x == thing) {
return something useful
}
}
I guess that's even clearer in Python where you iterate by writing
for thing in Y:
This looks to me like a general rule that trumps a rule which merely
stems from the happenstantial syntactic similarity between arrays and
associative arrays.
--bb
Re: DFL IDE Editor ?
Robert Jacques дµ½: On Thu, 24 Sep 2009 16:31:56 -0400, dolive doliv...@sina.com wrote: Robert Jacques ôµ½: On Thu, 24 Sep 2009 14:21:55 -0400, dolive doliv...@sina.com wrote: Robert Jacques Ã�ôõÃÂ#65533; On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 doliv...@sina.com wrote: can DFL make ide editor ? can do expansion of the corresponding function? Yes. There's the Entice IDE (http://www.dprogramming.com/entice.php) Or the simpler DCode IDE(http://www.dprogramming.com/dcode.php) Or the Scintilla control if you want to roll your own (http://wiki.dprogramming.com/Dfl/ScintillaControl) thank you very much !!! but version is older,can do be upgraded to dmd2.032 ? thank you !!! dolive DFL hasn't been updated to DMD 2.032 yet. I've updated my local copy. Here's the link: https://jshare.johnshopkins.edu/xythoswfs/webui/_xy-3615403_1-t_VRRBqZAG yes, I use DFL is dmd2.032, Scintilla DFL Control version is older, is 2007 year. hope upgraded to dmd2.032 . how to make lib ? I use makescintillalib.bat is error, I copyed cpp directory to DFL directory. changed dmd_path, dmc change to dmd. can be compiled out .obj file. thank you ! dolive Sorry, I've never used the Scintilla control myself. If you just want to make DFL there is a makelib.bat file in the dfl directory. Do you have a DFL for dmd2.035 ? thank you very much ! dolive
Re: Revamping associative arrays
bearophile pisze: Piotrek: No! No! No! Maybe you are wrong. Life is complex so I am usually wrong, because it's hard to consider all sides of a thing, but sometimes other people are even more wrong :-) I didn't mean to be offensive. All people (including me) have tendency to claim that they point is the only right. In D set.keys needs a good amount of memory and time, it's useful only in special situations, for example when you are sure your AA is small. Andrei will probably push to add/replace something to find keys and a lazy way. Yes that could be good. Any views, ranges are option of course. However I was referring to semantics not mechanics. Refusing forever to use a popular (and usually quite appreciated) language just because you don't like a single small feature is stupid. I don't want to force you to like Python, but the choice of a language must be based on a bit more global evaluation of it. Every language under the sun has plenty warts. C++ has enough warts (far larger than the one you have listed) that you can write a big book on them, but people keep using it still. The more time I live the more stupid things I find in my behaviour. But to be honest I have longer list of reasons why I don't like Python - dynamic typing - whitespace indentation - performance - not friendly for C-syntax-boys like me - lack of many features that are in D and some more I find D to be sufficient alternative for all scripting language (good std library is a cure). I said it before but I can say it again. Using many languages when one should do is waste for my time and efficiency ;) C++ (or C in embedded systems)is used because of extremely big momentum created for years expressed in invested money in learning, software development, etc. But hopefully everything could be stopped. It's a matter of time and force. Not doing scripting any more too is probably a not smart thing to say, because in most programming jobs I've seen, there are small files to munge, commands to automate, things to show or plot, and so on, etc. A scripting language (even just shell scripting) is designed for such things. It's not my choice and I'm glad here. My duties don't include scripting any more. And to me, scripting languages are some kind of joke (having D around). Despite it could seem (at first look) that I'm against you I'm not (except that area connected with those creatures). I really like the benchmarking done by you and I really appreciate how much time (much much more than me of course) you gave this community. First I must pay same debts then maybe I will start the project I'm thinking of for long time. Cheers Piotrek
Re: Revamping associative arrays
bearophile wrote: Andrei Alexandrescu: I'm not sure whether much or any of this is attainable within D2. The things I've written about aren't all equally important and they don't require the same amount of work to be implemented. I am sorry for writing that gazpacho. There are two things that I think are more important that can implemented now: the opEquals among AAs, and the default iteration with foreach on the keys. The other things can wait. The opEquals among AAs requires probably less than 20 lines of code. You may want to submit those to bugzilla so they don't get forgotten. Two persons (plus Walter, of course) have said they don't like to iterate on the keys first. The other people have kept muzzle shut so I can't tell yet. Well clearly sometimes both are needed. I think it would be limiting to e.g. only offer iteration on keys, to then do one extra lookup to fetch the value. Andrei
Re: Revamping associative arrays
Bill Baxter pisze:
I think the default should be to iterate over whatever 'in' looks at.
I was almost convinced, because that rule has a sense. But treating
normal arrays and associative array has more sense to me.
fun (SomeObject object) {
foreach (element;object.arr1){ //normal, but how do I know at first look
//just do something with element
}
foreach (element;object.arr2){ // assoc, but how do I know at first look
//just do something with element hopefully not index
}
Cheers
Piotrek
Re: Revamping associative arrays
On Sun, Oct 18, 2009 at 1:12 PM, Piotrek star...@tlen.pl wrote:
Bill Baxter pisze:
I think the default should be to iterate over whatever 'in' looks at.
I was almost convinced, because that rule has a sense. But treating normal
arrays and associative array has more sense to me.
fun (SomeObject object) {
foreach (element;object.arr1){ //normal, but how do I know at first look
//just do something with element
}
foreach (element;object.arr2){ // assoc, but how do I know at first look
//just do something with element hopefully not index
}
That sounds like an argument that there should be no default, because
either way it's not clear whether you're iterating over keys or
values. That's reasonable too, I think. Just get rid of the the
one-argument foreach over AAs altogether and force the user to be
explicit about it. Probably much less error-prone than quietly
changing the D1 default, for sure. :-) As much as people go on about
making it easy to port C code, really ya gots to think about all the
D1 code too. It shouldn't be harder to port D1 code to D2 than C
code!
So for a new language I would go for what I said before. But for D, I
think the better move is to get rid of the one-arg foreach and require
.keys / .values explicitly. (And make that efficient, of course).
--bb
Re: 64-bit
Why I mentioned desktop applications is that currently the trend has been to replace old 32-bit intel/amd processors in desktop use. And most desktop apps are written in systems programming languages. You can hardly buy any non-64-bit capable processor from any pc store these days. The people are getting crap that they don't need. The same thing happens with digital cameras. In cameras the pixel count of sensors is growing even though the image quality stays the same. A good quality 4 MPix camera is much better than a cheap 15 MPix pocket camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored in jpg format might look better than the original 15 MPix one in raw format. They just keep pushing the limits to sell larger and larger storage media. You'd probably be pissed to hear about microsoft creating a 128-bit OS and intel designing 128-bit processors.
Re: 64-bit
Sun, 18 Oct 2009 14:45:39 -0600, Stanley Steel thusly wrote: Why I mentioned desktop applications is that currently the trend has been to replace old 32-bit intel/amd processors in desktop use. And most desktop apps are written in systems programming languages. You can hardly buy any non-64-bit capable processor from any pc store these days. The people are getting crap that they don't need. The same thing happens with digital cameras. In cameras the pixel count of sensors is growing even though the image quality stays the same. A good quality 4 MPix camera is much better than a cheap 15 MPix pocket camera. Even the forementioned 4 MPix pic resized to 2 MPix and stored in jpg format might look better than the original 15 MPix one in raw format. They just keep pushing the limits to sell larger and larger storage media. You'd probably be pissed to hear about microsoft creating a 128-bit OS and intel designing 128-bit processors. Nah, I don't really care. I have nothing against wider vector registers, but huge general purpose registers usually don't make sense.
The demise of T[new]
The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining. The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. What do you think?
Re: The demise of T[new]
Walter Bright:
Andrei had the idea that T[new] could be dispensed with by making a
builder library type to handle creating arrays by doing things like
appending, and then delivering a finished T[] type. This is similar to
what std.outbuffer and std.array.Appender do, they just need a bit of
refining.
I like how Andrei keeps trying to invent new possible ideas.
Sometimes situations can be improved adding things, and some other times
removing things.
So arrays will keep being kinda values, so if inside a function you use an
appender to add items to an array, outside the function, when the function
returns, you will keep seeing the original shorter array. This is not fully
intuitive (but you can get used to it just because you use arrays all the time).
The following code is not possible any more because you can't change the length:
import std.stdio: writefln;
void main() {
int[] a1 = new int[5];
a1[] = 1;
int[] a2 = a1[1..3];
writefln(a1, , a2); // [1,1,1,1,1] [1,1]
a2.length = a2.length + 4;
writefln(a1, , a2); // [1,1,1,1,1] [1,1,0,0,0,0]
}
But how do you change the length of an array (because appending many single
items isn't always what you need to do)?
And how does that interacts with the slicing, as in this code example?
Bye,
bearophile
Re: Revamping associative arrays
Piotrek wrote: bearophile Wrote: I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key I can find its value, while the opposite is not possible, so having keys is much more useful. This is true in Python too. In my dlibs all iterables and functions behave like this. The current D design is just a design mistake ad Walter was wrong on this. No! No! No! Maybe you are wrong. Or it's a metter of taste. I remember that I spent many hours on finding bug in python's script written by me in my job. The reason was the python's behaviour decribed by you. Then I couldn't understand why the hell iterating on collection returns a key in the first place. It's so not intuitive. Your explanation is not even close in convincing me. If I wanted keys I would write: foreach (key, value; set) or (key; set.keys) In a perfect world, iterating over an AA would yield a tuple (key, value). You could iterate over either the keys or values by iterating over a view on the key or value list. I'm surprised Python doesn't do that. (I'm expecting that Andrei will replace the .key and .value properties by lazy ranges, that don't allocate memory; so that aspect will be alright. But too bad the gods don't see the need for better tuple support.)
Re: Revamping associative arrays
Bill Baxter: It shouldn't be harder to port D1 code to D2 than C code! In the world for every line of D1 code you may want to port to D2, there are probably 100 or 1000+ lines of C code that you may want to port to D2, so the situation is not the same. Keeping compatibility with C is far more important than keeping compatibility with D1. Bye, bearophile
Re: The demise of T[new]
On Mon, 19 Oct 2009 01:05:39 +0400, Walter Bright newshou...@digitalmars.com wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining. The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. What do you think? Well, I personally don't feel much of a need for T[new], and I agree T[] needs to be fixed the way you describe (i.e. make a shrink-only range out of it). But I believe a change like this coupled with a demise of T[new] would be way too restricting. Given a T[] array; What type would result of these operations be? 1) auto x = array.dup; 2) auto y = array ~ array; T[] is a view into someone else's container. But when you create a new array (by dup'ing or concatenating), you get a fresh copy. It points to a beginning of data sequence, and there is nothing wrong to expand it. I believe it should be T[new]. A reference type, yes, a type that would allow appending and would render Appender unnecessary.
Re: Revamping associative arrays
On Mon, 19 Oct 2009 01:37:36 +0400, bearophile bearophileh...@lycos.com wrote: Bill Baxter: It shouldn't be harder to port D1 code to D2 than C code! In the world for every line of D1 code you may want to port to D2, there are probably 100 or 1000+ lines of C code that you may want to port to D2, so the situation is not the same. Keeping compatibility with C is far more important than keeping compatibility with D1. Bye, bearophile Why would you want to port C code to D, if you can easily interface with it?
Re: Revamping associative arrays
grauzone: In a perfect world, iterating over an AA would yield a tuple (key, value). You could iterate over either the keys or values by iterating over a view on the key or value list. I'm surprised Python doesn't do that. I don't know why Python has originally chosen to iterate on just keys, maybe it's a performance optimization (iterating on pairs is slower, because a single reference needs no allocation, while a tuple of 2 may need it, in practice CPython uses the same memory for the tuple, avoiding allocating it at every loop cycle), or maybe for one of the reasons I've explained. I don't know if D can make looping on key-value of built-in AAs as fast as iterating on just keys or just values. Iterating on AA keys or values is a very common operation that must be fast. (I'm expecting that Andrei will replace the .key and .value properties by lazy ranges, that don't allocate memory; so that aspect will be alright. At least, the range of the keys supports a O(1) opIn_r, I hope :-) Bye, bearophile
Re: The demise of T[new]
Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? What do you think? Whether T[new] is bultin (mostly implemented in the runtime), or a library type (implemented in Phobos) doesn't make much a difference; it's pretty much the same, isn't it? I don't understand what the exact reasons for this decision. If anything, the array type should be available without additional Phobos imports (i.e. it should be declared in object.d). Ease of access and ease of use is the key thing here.
Re: The demise of T[new]
grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei
Re: Revamping associative arrays
Denis Koroskin: Why would you want to port C code to D, if you can easily interface with it? First of all you have to consider programmer experience, they know C, so keeping the language backwards compatible with C helps them avoid bugs and learn D faster. If you ignore what programmers know, and you assume an easy interface between a new language and C, then you don't need to design a language like C++/D, that keeps lot of little compatibility with C, you are more free, and you can avoid warts like the design of C switch(). I have ported some thousands of lines of C code to D. Surely there are situations where keeping a large amount of C code is the best thing do to, and saves you lot of time and work. But other times you may want to port the C code. Some of the reasons you may have to port C code to D: - because I like the look of D code more than D code; - because the original C code may be so old and ugly that keeping it in my project hurts my aesthetic sense; - gives me more safety than certain C code; - allows me to use a GC that may be safer than the original manual memory management; - because I may use my dlibs and shorten the original C code. Less code is usually a good thing; - because I will probably need to change and improve the code and I prefer to do it on D code that's nicer and allows me to program in a faster way; - because I use bud to compile small D projects and in them adding a C dependency requires more time than translating 20 lines of C code and adding it into an already existing D module; - because I am creating some pure D library, to keep things simpler and tidy. - I'd even like to see the official D2 compiler to be written in D1/D2 (and a little of assembly). Bye, bearophile
Re: The demise of T[new]
On Mon, 19 Oct 2009 01:55:28 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Denis Koroskin wrote:
On Mon, 19 Oct 2009 01:05:39 +0400, Walter Bright
newshou...@digitalmars.com wrote:
The purpose of T[new] was to solve the problems T[] had with passing
T[] to a function and then the function resizes the T[]. What happens
with the original?
The solution we came up with was to create a third array type, T[new],
which was a reference type.
Andrei had the idea that T[new] could be dispensed with by making a
builder library type to handle creating arrays by doing things like
appending, and then delivering a finished T[] type. This is similar to
what std.outbuffer and std.array.Appender do, they just need a bit of
refining.
The .length property of T[] would then become an rvalue only, not an
lvalue, and ~= would no longer be allowed for T[].
We both feel that this would simplify D, make it more flexible, and
remove some awkward corner cases like the inability to say a.length++.
What do you think?
Well, I personally don't feel much of a need for T[new], and I agree
T[] needs to be fixed the way you describe (i.e. make a shrink-only
range out of it).
But I believe a change like this coupled with a demise of T[new] would
be way too restricting. Given a
T[] array;
What type would result of these operations be?
1) auto x = array.dup;
2) auto y = array ~ array;
T[] is a view into someone else's container. But when you create a new
array (by dup'ing or concatenating), you get a fresh copy. It points to
a beginning of data sequence, and there is nothing wrong to expand it.
I believe it should be T[new]. A reference type, yes, a type that
would allow appending and would render Appender unnecessary.
That was the exact plan. I even have half a chapter written about it
with nice figures and all, that I can make available. The problem was,
it sucked. Returning a distinct type from .dup and ~ makes slices not
closed over these operations, a source of complication, confusion, and
bloating.
Andrei
What's problem with implicit cast of T[new] to T[]?
T[new] container = [1, 2, 3].dup;
T[] range1 = container; // implicit container[] call via alias this
T[] range2 = [1, 2, 3].dup; // same here
An other option would be to declare
// duplicates a range
T[] rdup(T[] range)
{
return range.dup[];
}
but it's less likely to happen.
Re: The demise of T[new]
== Quote from Walter Bright (newshou...@digitalmars.com)'s article The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining. The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. What do you think? This is ridiculous. The status quo works well most of the time and just has a few really ugly corner cases. As long as you're only appending to one array at a time, appending isn't even that slow anymore now that bug 2900 (http://d.puremagic.com/issues/show_bug.cgi?id=2900) is fixed. I frankly think it's absurd to make working with arrays an order of magnitude harder and less elegant in the 90+% of cases where they work fine just to fix a few corner case bugs. Don't get me wrong, the corner case bugs should be fixed because they're pretty nasty safety issues. They just shouldn't be fixed in a way that makes arrays substantially harder to use, or even syntactically uglier, in the cases where they already work well. As good a programmer as Andrei is, I'm sure whatever he comes up with will be much less syntactially pleasing and easy to use than something the core language understands. Here's my proposal for how T[new] should work: 1. It should be a reference type to be consistent with slices. Yes, slices are kind of a hybrid, but they're more semantically similar to reference types than value types. If you can't modify the length of a slice anymore, then for all practical purposes it will be a reference type. 2. A T[new] should support all the same operations as a T[] with semantics as similar as common sense will allow, including indexing, ~, .dup, .idup, slice assign, etc. Basically, it should have, to the greatest degree possible without defeating the purpose, the same compile time interface. 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo is a T[new]. T[] bar = someFunctionThatReturnsTnew(); // Works. bar is a T[]. The T[new] went into oblivion. This solves the problem of slices not being closed over .dup and ~. 4. It should be guaranteed that no block of memory is ever referenced by more than one T[new] instance. This is needed to guarantee safety when appending to immutable arrays, etc. 5. Assigning a T[new] to another T[new] should be by reference, just like assigning a class instance to another class instance. Assigning a T[] to a T[new] should duplicate the memory block referenced by the T[] because this is probably the only way to guarantee (4). 6. Since T[new] guarantees unique access to a memory block, it should have an assumeUnique() method that returns an immutable slice and sets the T[new]'s reference to the memory block to null. This solves the problem of building immutable arrays without the performance penalty of not being able to pre-allocate or the unsafeness of having to cowboy cast it to immutable. 7. As long as the GC is conservative, there absolutely *must* be a method of manually freeing the memory block referenced by a T[new] provided that the GC supports this operation, though it doesn't have to be particularly pretty. In general, since D is a systems language, T[new] should not be too opaque. A good way to do this might be to make all of the fields of the T[new] public but undocumented. If you *really* want to mess with it, you'll read the source code and figure it out. 8. The first call to opSlice on a T[new] should set a flag that indicates that there may be multiple pointers to the underlying memory block. Before that flag is set, appends to a T[new] should result in calls to GC.free() to free the old block whenever it needs to be expanded (since we can guarantee that we own it exclusively). This will help deal with false pointer issues, since D's GC looks like it will remain conservative for the foreseeable future.
Re: Revamping associative arrays
Bill Baxter pisze:
On Sun, Oct 18, 2009 at 1:12 PM, Piotrek star...@tlen.pl wrote:
Bill Baxter pisze:
I think the default should be to iterate over whatever 'in' looks at.
I was almost convinced, because that rule has a sense. But treating normal
arrays and associative array has more sense to me.
fun (SomeObject object) {
foreach (element;object.arr1){ //normal, but how do I know at first look
//just do something with element
}
foreach (element;object.arr2){ // assoc, but how do I know at first look
//just do something with element hopefully not index
}
That sounds like an argument that there should be no default, because
either way it's not clear whether you're iterating over keys or
values.
Really?! That wasn't my intention :) In both cases I wish it were values ;)
Just get rid of the the one-argument foreach over AAs altogether and
force the user to be
explicit about it.
I wouldn't do so. Would anybody do an error by thinking that foreach
(elem,table) should iterate over keys?
Maybe I'm not thinking correctly but for me an assoc array is just an
array with additional key (index) features thanks to which I save space
and/or have more indexing method than only integers.
e.g.
Normal array
No. Item
0 George
1 Fred
2 Dany
3 Lil
Index/key is infered from position (offset)
Now Assoc array:
No. Item
10 Lindsey
21 Romeo
1001C-Jay
Or
No. Item
first Europe
second South America
third Australia
Or
Names occurrence frequency:
No. Item
Andy21
John23
Kate12
And the only difference is the need for using a hash function for value
lookup (calculate position) which should not bother a user when he
doesn't care.
Then when you ask somebody to iterate over the tables, what he will do
almost for certain? If it would be me, you know... values all the time.
Even for last example most important values are those numbers (despite
in this case they're meaningless without keys).
Cheers
Piotrek
Re: Revamping associative arrays
Moritz Warning wrote: On Sat, 17 Oct 2009 18:58:08 +, BCS wrote: what will this do? foreach(key; aa.keys) if(Test(key)) aa.remove(key); It's undefined behavior. You shouldn't try to mutate the aa while iterating. I hope that will be fixed. It took me some time to find this out. That's really annoying, and it's true of most (all?) C# base class library collections. When coding in C#, I often find myself doing: var remove = new HashedSetFoo(); foreach (var foo in foos) if (Test(foo)) remove.Add(foo); foos.RemoveAll(remove); It's more allocation than necessary, but more than that, it's an unnecessarily complicated way of interacting with the collection.
Re: Revamping associative arrays
On Sun, Oct 18, 2009 at 3:28 PM, Piotrek star...@tlen.pl wrote:
Bill Baxter pisze:
On Sun, Oct 18, 2009 at 1:12 PM, Piotrek star...@tlen.pl wrote:
Bill Baxter pisze:
I think the default should be to iterate over whatever 'in' looks at.
I was almost convinced, because that rule has a sense. But treating
normal
arrays and associative array has more sense to me.
fun (SomeObject object) {
foreach (element;object.arr1){ //normal, but how do I know at first look
//just do something with element
}
foreach (element;object.arr2){ // assoc, but how do I know at first look
//just do something with element hopefully not index
}
That sounds like an argument that there should be no default, because
either way it's not clear whether you're iterating over keys or
values.
Really?! That wasn't my intention :) In both cases I wish it were values ;)
Got that, but we got two explanations for the most logical behavior.
I like my explanation, you like yours. Given that in a sample size
of like 4 here we can't agree, I don't see much hope of there being
overwhelming agreement on the right behavior in the population at
large. Seems like there's interest in making it harder to make
mistakes with D (see the T[new] discussion), and there's a genuine
ambiguity here so the user should be made to specify what they want.
Otherwise it's easy to make mistakes. I know I've gotten wrong
before. To the point where I pretty much always just use the
foreack(k,v; AA) form now just to be sure. Even if I don't need the
values. Or the keys or whichever it is ;-)
Just get rid of the the one-argument foreach over AAs altogether and force
the user to be
explicit about it.
I wouldn't do so. Would anybody do an error by thinking that foreach
(elem,table) should iterate over keys?
Bearophile. And anyone coming from python, at the least. And anyone
who agrees with the logic of connecting 'in' with what gets iterated.
Maybe I'm not thinking correctly but for me an assoc array is just an array
with additional key (index) features thanks to which I save space and/or
have more indexing method than only integers.
It can also be thought of as a set with some ancillary data associated
with each element. In that case the keys are the set elements, and
the values are just some extra stuff hanging off the elements.
--bb
Re: Revamping associative arrays
Piotrek wrote: bearophile Wrote: I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key I can find its value, while the opposite is not possible, so having keys is much more useful. This is true in Python too. In my dlibs all iterables and functions behave like this. The current D design is just a design mistake ad Walter was wrong on this. No! No! No! Maybe you are wrong. Or it's a metter of taste. I remember that I spent many hours on finding bug in python's script written by me in my job. The reason was the python's behaviour decribed by you. Then I couldn't understand why the hell iterating on collection returns a key in the first place. It's so not intuitive. Your explanation is not even close in convincing me. If I wanted keys I would write: foreach (key, value; set) or (key; set.keys) Why not mandate using both keys and values? That should eliminate ambiguity. Essentially, an associative array would be a Tuple!(Tkey, Tvalue)[] with some extra accessors.
Re: The demise of T[new]
dsimcha wrote: Here's my proposal for how T[new] should work: 1. It should be a reference type to be consistent with slices. Yes, slices are kind of a hybrid, but they're more semantically similar to reference types than value types. If you can't modify the length of a slice anymore, then for all practical purposes it will be a reference type. Check. 2. A T[new] should support all the same operations as a T[] with semantics as similar as common sense will allow, including indexing, ~, .dup, .idup, slice assign, etc. Basically, it should have, to the greatest degree possible without defeating the purpose, the same compile time interface. Check. 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo is a T[new]. T[] bar = someFunctionThatReturnsTnew(); // Works. bar is a T[]. The T[new] went into oblivion. This solves the problem of slices not being closed over .dup and ~. Check. 4. It should be guaranteed that no block of memory is ever referenced by more than one T[new] instance. This is needed to guarantee safety when appending to immutable arrays, etc. That doesn't go with reference semantics. Uncheck. 5. Assigning a T[new] to another T[new] should be by reference, just like assigning a class instance to another class instance. Check. (BTW contradicts 4) Assigning a T[] to a T[new] should duplicate the memory block referenced by the T[] because this is probably the only way to guarantee (4). No check, but could have been done. 6. Since T[new] guarantees unique access to a memory block, it should have an assumeUnique() method that returns an immutable slice and sets the T[new]'s reference to the memory block to null. This solves the problem of building immutable arrays without the performance penalty of not being able to pre-allocate or the unsafeness of having to cowboy cast it to immutable. Uncheck. 7. As long as the GC is conservative, there absolutely *must* be a method of manually freeing the memory block referenced by a T[new] provided that the GC supports this operation, though it doesn't have to be particularly pretty. In general, since D is a systems language, T[new] should not be too opaque. A good way to do this might be to make all of the fields of the T[new] public but undocumented. If you *really* want to mess with it, you'll read the source code and figure it out. Check while delete still exists. Please use malloc for that stuff. 8. The first call to opSlice on a T[new] should set a flag that indicates that there may be multiple pointers to the underlying memory block. Before that flag is set, appends to a T[new] should result in calls to GC.free() to free the old block whenever it needs to be expanded (since we can guarantee that we own it exclusively). This will help deal with false pointer issues, since D's GC looks like it will remain conservative for the foreseeable future. Uncheck. So now: every place I've said check means there was implementation and book-quality illustrated documentation that Walter and I have done with the sweat of our brow. At the end we looked at the result and concluded we should throw away all that work. Andrei
Re: The demise of T[new]
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo is a T[new]. T[] bar = someFunctionThatReturnsTnew(); // Works. bar is a T[]. The T[new] went into oblivion. This solves the problem of slices not being closed over .dup and ~. Check. So then why is slices not being closed over .dup, ~, etc. still a problem? With implicit conversion, they for all practical purposes are. 4. It should be guaranteed that no block of memory is ever referenced by more than one T[new] instance. This is needed to guarantee safety when appending to immutable arrays, etc. That doesn't go with reference semantics. Uncheck. 5. Assigning a T[new] to another T[new] should be by reference, just like assigning a class instance to another class instance. Check. (BTW contradicts 4) There was a slight misunderstanding here. When I say an instance, I mean one T[new] heap object == one instance, no matter how many pointers/references to this instance you have. The assumption is that T[new] objects live entirely on the heap and have semantics similar to classes. For example: uint[new] foo = new uint[100]; uint[new] bar = foo; // Really just a pointer assignment. Now, both foo and bar point to the same uint[new] instance. If anything is modified via foo, it is seen when viewed from bar and vice-versa. To clarify, no *main block of memory that holds the data in the array* is ever referenced by more than one T[new] *heap object*. Assigning a T[] to a T[new] should duplicate the memory block referenced by the T[] because this is probably the only way to guarantee (4). No check, but could have been done. Actually, this can even be done by COW. Initially, assigning a T[] to a T[new] could just be a pointer assignment and setting a flag, as long as a copy of the data is made when you try to increase the length of the T[new] or append to it. Basically, as long as you use the T[new] as if it were a T[], no copying needs to be done. 6. Since T[new] guarantees unique access to a memory block, it should have an assumeUnique() method that returns an immutable slice and sets the T[new]'s reference to the memory block to null. This solves the problem of building immutable arrays without the performance penalty of not being able to pre-allocate or the unsafeness of having to cowboy cast it to immutable. Uncheck. Now that I've explained my uniqueness thing better, does this sound feasible? 7. As long as the GC is conservative, there absolutely *must* be a method of manually freeing the memory block referenced by a T[new] provided that the GC supports this operation, though it doesn't have to be particularly pretty. In general, since D is a systems language, T[new] should not be too opaque. A good way to do this might be to make all of the fields of the T[new] public but undocumented. If you *really* want to mess with it, you'll read the source code and figure it out. Check while delete still exists. Please use malloc for that stuff. As long as I can get at the pointer to the memory block held by T[new] I can pass it to GC.free. All that would really be needed is a .ptr property that does something like what .ptr does for T[]s. So now: every place I've said check means there was implementation and book-quality illustrated documentation that Walter and I have done with the sweat of our brow. At the end we looked at the result and concluded we should throw away all that work. Andrei This begs the question: Why? Walter's post on the subject was rather brief and I can't understand for the life of me why you guys would throw away such an elegant solution. Given that we already agree that a T[new] can be implicitly cast to a T[], the lack of closure under ~, .dup, etc. seems like a non-issue. When I was a beginner, before I got into templates, a major attraction to D was that it was a fast, compiled language where basic things like arrays (mostly) just worked. To take away all the syntactic sugar for appending and lengthening from arrays and push this into a separate library type that doesn't feel like a first class object or (I assume) even support most array semantics would be a massive, massive kludge no matter how well-implemented that library type was.
Re: The demise of T[new]
dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo is a T[new]. T[] bar = someFunctionThatReturnsTnew(); // Works. bar is a T[]. The T[new] went into oblivion. This solves the problem of slices not being closed over .dup and ~. Check. So then why is slices not being closed over .dup, ~, etc. still a problem? With implicit conversion, they for all practical purposes are. The problems are with auto and template argument deduction. 4. It should be guaranteed that no block of memory is ever referenced by more than one T[new] instance. This is needed to guarantee safety when appending to immutable arrays, etc. That doesn't go with reference semantics. Uncheck. 5. Assigning a T[new] to another T[new] should be by reference, just like assigning a class instance to another class instance. Check. (BTW contradicts 4) There was a slight misunderstanding here. When I say an instance, I mean one T[new] heap object == one instance, no matter how many pointers/references to this instance you have. The assumption is that T[new] objects live entirely on the heap and have semantics similar to classes. For example: uint[new] foo = new uint[100]; uint[new] bar = foo; // Really just a pointer assignment. Now, both foo and bar point to the same uint[new] instance. If anything is modified via foo, it is seen when viewed from bar and vice-versa. To clarify, no *main block of memory that holds the data in the array* is ever referenced by more than one T[new] *heap object*. Oh yah. Check that sucker. Assigning a T[] to a T[new] should duplicate the memory block referenced by the T[] because this is probably the only way to guarantee (4). No check, but could have been done. Actually, this can even be done by COW. Initially, assigning a T[] to a T[new] could just be a pointer assignment and setting a flag, as long as a copy of the data is made when you try to increase the length of the T[new] or append to it. Basically, as long as you use the T[new] as if it were a T[], no copying needs to be done. 6. Since T[new] guarantees unique access to a memory block, it should have an assumeUnique() method that returns an immutable slice and sets the T[new]'s reference to the memory block to null. This solves the problem of building immutable arrays without the performance penalty of not being able to pre-allocate or the unsafeness of having to cowboy cast it to immutable. Uncheck. Now that I've explained my uniqueness thing better, does this sound feasible? Nah, there are still problems with Ts that themselves are elaborate types containing references, aliasing etc. assumeUnique makes a rather strong claim. 7. As long as the GC is conservative, there absolutely *must* be a method of manually freeing the memory block referenced by a T[new] provided that the GC supports this operation, though it doesn't have to be particularly pretty. In general, since D is a systems language, T[new] should not be too opaque. A good way to do this might be to make all of the fields of the T[new] public but undocumented. If you *really* want to mess with it, you'll read the source code and figure it out. Check while delete still exists. Please use malloc for that stuff. As long as I can get at the pointer to the memory block held by T[new] I can pass it to GC.free. All that would really be needed is a .ptr property that does something like what .ptr does for T[]s. Alrighty. Check that. So now: every place I've said check means there was implementation and book-quality illustrated documentation that Walter and I have done with the sweat of our brow. At the end we looked at the result and concluded we should throw away all that work. Andrei This begs the question: Why? Walter's post on the subject was rather brief and I can't understand for the life of me why you guys would throw away such an elegant solution. Here's what I wrote to Walter: I'm going to suggest something terrible - let's get rid of T[new]. I know it's difficult to throw away work you've already done, but really things with T[new] start to look like a Pyrrhic victory. Here are some issues: * The abstraction doesn't seem to come off as crisp and clean as we both wanted; * There are efficiency issues, such as the two allocations that you valiantly tried to eliminate in a subset of cases; * Explaining two very similar but subtly different types to newcomers is excruciatingly difficult (I'll send you a draft of the chapter - it looks like a burn victim who didn't make it); * Furthermore, explaining people when to use one vs. the other is much more difficult than it seems. On the surface, it goes like this: If you need to append stuff, use T[new]. If not, use T[]. Reality is much more subtle. For one thing, T[new] does not allow
Re: DFL IDE Editor ?
On Sun, 18 Oct 2009 15:19:28 -0400, dolive doliv...@sina.com wrote: Robert Jacques дµ½: On Thu, 24 Sep 2009 16:31:56 -0400, dolive doliv...@sina.com wrote: Robert Jacques Ã�´µ½: On Thu, 24 Sep 2009 14:21:55 -0400, dolive doliv...@sina.com wrote: Robert Jacques Ã�´µÂÂ#65533; On Thu, 24 Sep 2009 06:22:57 -0400, dolive89 doliv...@sina.com wrote: can DFL make ide editor ? can do expansion of the corresponding function? Yes. There's the Entice IDE (http://www.dprogramming.com/entice.php) Or the simpler DCode IDE(http://www.dprogramming.com/dcode.php) Or the Scintilla control if you want to roll your own (http://wiki.dprogramming.com/Dfl/ScintillaControl) thank you very much !!! but version is older,can do be upgraded to dmd2.032 ? thank you !!! dolive DFL hasn't been updated to DMD 2.032 yet. I've updated my local copy. Here's the link: https://jshare.johnshopkins.edu/xythoswfs/webui/_xy-3615403_1-t_VRRBqZAG yes, I use DFL is dmd2.032, Scintilla DFL Control version is older, is 2007 year. hope upgraded to dmd2.032 . how to make lib ? I use makescintillalib.bat is error, I copyed cpp directory to DFL directory. changed dmd_path, dmc change to dmd. can be compiled out .obj file. thank you ! dolive Sorry, I've never used the Scintilla control myself. If you just want to make DFL there is a makelib.bat file in the dfl directory. Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you.
Re: The demise of T[new]
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
3. A T[new] should be implicitly convertible to a slice. For example:
auto foo = someFunctionThatReturnsTnew();
// foo is a T[new].
T[] bar = someFunctionThatReturnsTnew();
// Works. bar is a T[]. The T[new] went into oblivion.
This solves the problem of slices not being closed over .dup and ~.
Check.
So then why is slices not being closed over .dup, ~, etc. still a problem?
With
implicit conversion, they for all practical purposes are.
The problems are with auto and template argument deduction.
Ok, now I can see how this would be a legitimate problem, but only in a few
corner
cases:
void doStuff(T)(T someArrayLikeObject) {
someArrayLikeObject = someArrayLikeObject[0..$ - 1];
}
int[] foo = someFunction();
int[] bar = someFunction();
auto baz = foo ~ bar;
// baz is an int[new]. This doesn't usually matter, since you can use it
// just like an int[] and if you care about the small performance difference,
// you should be more careful.
doStuff(baz);
// Are the effects of doStuff() visible in this scope?
// Depends if baz is an int[] or an int[new].
However, this is really, really, *really* a corner case. Any reasonable
template
would either slice the array to make sure it owns the slice information or pass
by
reference to make sure the change is propagated, so that there is no ambiguity.
Here's what I wrote to Walter:
I'm going to suggest something terrible - let's get rid of T[new]. I
know it's difficult to throw away work you've already done, but really
things with T[new] start to look like a Pyrrhic victory. Here are some
issues:
* The abstraction doesn't seem to come off as crisp and clean as we both
wanted;
* There are efficiency issues, such as the two allocations that you
valiantly tried to eliminate in a subset of cases;
Once you've opened the can of worms of having to perform allocations, one versus
two allocations isn't very important.
* Explaining two very similar but subtly different types to newcomers is
excruciatingly difficult (I'll send you a draft of the chapter - it
looks like a burn victim who didn't make it);
This is admittedly a legitimate concern. However, you can get off the ground in
D, or any language for that matter, without being a full-fledged language
lawyer.
I frankly don't think it's important for beginners to understand every subtlety
and corner case. Heck, I've been using D for a while and have done some
non-trivial projects in it and there are definitely dark corners that I don't
understand. (Complex numbers come to mind.) I just don't care because I figure
I'll learn them if/when I need to know them.
* Furthermore, explaining people when to use one vs. the other is much
more difficult than it seems. On the surface, it goes like this: If you
need to append stuff, use T[new]. If not, use T[]. Reality is much more
subtle. For one thing, T[new] does not allow contraction from the left,
whereas T[] does. That puts T[] at an advantage. So if you want to
append stuff and also contract from the left, there's nothing our
abstractions can help you with.
Why can't a T[new] contract from the left? As far as I can tell, you could do
something like:
struct TNew(T) {
typeof(this) opAssign(T[] slice) {
if(slice.ptr = this.ptr slice.ptr this.ptr + capacity) {
// Then we own this block of memory and can assign
// a slice by reference.
// Adjust effective capacity.
capacity -= cast(size_t) (slice.ptr - this.ptr);
length = slice.length;
this.ptr = slice.ptr;
} else {
// Assign the slice by copying.
}
}
// Other stuff.
}
You would then contract from the left the same way as for a slice:
int[new] foo = new int[5];
foo = foo[1..$];
It would simply require a few integer/pointer comparisons and still be
reasonably
efficient.
Instead of all T[new] stuff, I suggest the following:
1. We stay with T[] and we define a struct ArrayBuilder that replaces
T[new] with a much more clear name and charter. Phobos already has
Appender which works very well. We can beef that up to allow array-like
primitives.
2. Assigning to a slice's .length allocates a new slice if growth is needed.
3. Disallow ~= for slices. ArrayBuilder will define it.
4. That's it.
Java got away with a similar approach using StringBuilder:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html
Scala has something very similar called ArrayBuffer:
http://www.nabble.com/ArrayList-and-ArrayBuffer-td15448842.html
And guess what, C# stole Java's StringBuilder as well:
http://msdn.microsoft.com/en-us/library/2839d5h5%28VS.71%29.aspx
So it looks like many programmers coming from other languages will
already be familiar with the
Re: The demise of T[new]
Walter Bright wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining. The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. What do you think? I think ArrayBuilder can work almost entirely transparently provided the following conditions are met: 1) when trying to cat to an array, the first array automatically promotes to ArrayBuilder 2) Setting .length is, depending on new length, either a slice or a cat operation with the length difference. 2) ArrayBuilders implicitly cast to string. This should allow a syntax that is almost entirely identical to the one used in D1, aside from typeof(a~b).stringof :) Is this feasible in D2?
Re: The demise of T[new]
== Quote from downs (default_357-l...@yahoo.de)'s article Walter Bright wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining. The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. What do you think? I think ArrayBuilder can work almost entirely transparently provided the following conditions are met: 1) when trying to cat to an array, the first array automatically promotes to ArrayBuilder 2) Setting .length is, depending on new length, either a slice or a cat operation with the length difference. 2) ArrayBuilders implicitly cast to string. This should allow a syntax that is almost entirely identical to the one used in D1, aside from typeof(a~b).stringof :) Is this feasible in D2? Once you throw in all the implicit conversions to ArrayBuilder and having the core language know about ArrayBuilder, aren't you, for all practical purposes, implementing T[new] but calling it ArrayBuilder?
Re: The demise of T[new]
Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei removing syntactic sugar doesn't really remove corner cases. T[new] is being replaced with an array builder. What usage semantics are given up with an array builder? How will implicit conversions be handled? (alias this, etc...). How will the Phobos array buiilder support user specified lengths (for efficiency)?
Re: The demise of T[new]
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei removing syntactic sugar doesn't really remove corner cases. T[new] is being replaced with an array builder. What usage semantics are given up with an array builder? How will implicit conversions be handled? (alias this, etc...). How will the Phobos array buiilder support user specified lengths (for efficiency)? I think ArrayBuilder could a logic similar to Appender for ~= and otherwise offer regular array primitives. I don't think implicit conversion to T[] is an essential feature, but it can be done. Andrei So basically, ArrayBuilder would be like T[new], except: 1. It would be a plain old library type, and the core language would know nothing about it. 2. T[].dup, T[] ~ T[], new T[3], etc. would return T[], not ArrayBuilder/T[new]. Is this basically correct?
Re: The demise of T[new]
Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei removing syntactic sugar doesn't really remove corner cases. T[new] is being replaced with an array builder. What usage semantics are given up with an array builder? How will implicit conversions be handled? (alias this, etc...). How will the Phobos array buiilder support user specified lengths (for efficiency)? I think ArrayBuilder could a logic similar to Appender for ~= and otherwise offer regular array primitives. I don't think implicit conversion to T[] is an essential feature, but it can be done. Andrei
Re: The demise of T[new]
dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei removing syntactic sugar doesn't really remove corner cases. T[new] is being replaced with an array builder. What usage semantics are given up with an array builder? How will implicit conversions be handled? (alias this, etc...). How will the Phobos array buiilder support user specified lengths (for efficiency)? I think ArrayBuilder could a logic similar to Appender for ~= and otherwise offer regular array primitives. I don't think implicit conversion to T[] is an essential feature, but it can be done. Andrei So basically, ArrayBuilder would be like T[new], except: 1. It would be a plain old library type, and the core language would know nothing about it. 2. T[].dup, T[] ~ T[], new T[3], etc. would return T[], not ArrayBuilder/T[new]. Is this basically correct? Yes, that's the plan. I hope you're not setting me up or something :o). Andrei
Proposed D2 Feature: = for anonymous delegates
Am I the only one that has trouble remembering how to write an inline anonymous
delegate when calling a function? At a minimum, both Scala and C# use (args) =
{ body; } syntax. Can we please sneak it into D2?
Re: Proposed D2 Feature: = for anonymous delegates
Jason House wrote:
Am I the only one that has trouble remembering how to write an inline
anonymous delegate when calling a function? At a minimum, both Scala
and C# use (args) = { body; } syntax. Can we please sneak it into
D2?
We have (args) { body; }
Andrei
Re: The demise of T[new]
Andrei Alexandrescu Wrote: dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei removing syntactic sugar doesn't really remove corner cases. T[new] is being replaced with an array builder. What usage semantics are given up with an array builder? How will implicit conversions be handled? (alias this, etc...). How will the Phobos array buiilder support user specified lengths (for efficiency)? I think ArrayBuilder could a logic similar to Appender for ~= and otherwise offer regular array primitives. I don't think implicit conversion to T[] is an essential feature, but it can be done. Andrei So basically, ArrayBuilder would be like T[new], except: 1. It would be a plain old library type, and the core language would know nothing about it. 2. T[].dup, T[] ~ T[], new T[3], etc. would return T[], not ArrayBuilder/T[new]. Is this basically correct? Yes, that's the plan. I hope you're not setting me up or something :o). Andrei I was ;) Well, only sort of. I'm undecided if array-like syntactic sugar makes sense for array builder. Afterall, AA's fit into a similar category. I did notice you wanted to make array builder a struct which implies it won't be used in the same manner as T[new]
Re: Proposed D2 Feature: = for anonymous delegates
Andrei Alexandrescu Wrote:
Jason House wrote:
Am I the only one that has trouble remembering how to write an inline
anonymous delegate when calling a function? At a minimum, both Scala
and C# use (args) = { body; } syntax. Can we please sneak it into
D2?
We have (args) { body; }
Andrei
Somehow, I missed that. What kind of type inference, if any, is allowed? Scala
and C# allow omiting the type. Lately I'm doing a lot of (x) = { return
x.foo(7); } in C# and it's nice to omit the amazingly long type for x. The IDE
even knows the type of x for intellisense... I think scala would allow x =
foo(7), or maybe even = _.foo(7) or even _.foo(7). I haven't written much
scala, so I may be way off...
Re: dmd support for IDEs and the D tool chain
Hello Nick, BCS n...@anon.com wrote in message If mine did that I'd shoot him (a scorching e-mail :) You should both feel lucky. The best I had was a class where we filled in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* professor for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to. And I'm not even at a well know CS school. I'd have asked for my money back.
Re: dmd support for IDEs and the D tool chain
Hello Ellery, BCS wrote: Hello Ellery, For some reason, my professor seems to be skipping LR parsing. If mine did that I'd shoot him (a scorching e-mail :) It's probably because he can't make us write a LALR parser by hand. For a small language he could. My prof has done several 2-4 production grammars, by hand, on the board, in class!
Re: The demise of T[new]
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei removing syntactic sugar doesn't really remove corner cases. T[new] is being replaced with an array builder. What usage semantics are given up with an array builder? How will implicit conversions be handled? (alias this, etc...). How will the Phobos array buiilder support user specified lengths (for efficiency)? I think ArrayBuilder could a logic similar to Appender for ~= and otherwise offer regular array primitives. I don't think implicit conversion to T[] is an essential feature, but it can be done. Andrei So basically, ArrayBuilder would be like T[new], except: 1. It would be a plain old library type, and the core language would know nothing about it. 2. T[].dup, T[] ~ T[], new T[3], etc. would return T[], not ArrayBuilder/T[new]. Is this basically correct? Yes, that's the plan. I hope you're not setting me up or something :o). Andrei Given the issues surrounding T[new] and how ugly some cases of the implicit conversion can get, you've convinced me that this may be a good solution as long as: 1. ArrayBuilder implements full array semantics and is usable as a real array as you suggest. I wasn't aware that this was what was being proposed, as ArrayBuilder implied to me that it's only good for building arrays as opposed to being a full-fledged array library type. Ideally, for convenience it should be implicitly convertible to T[]. 2. The semantics are such that bug 2093 (http://d.puremagic.com/issues/show_bug.cgi?id=2093) is fixed, while still allowing appending to arrays of immutables. This would probably require some casting under the hood, but the standard lib. is only one step above the core language, so it's acceptable. The semantics of the length property would probably have to be reference semantics, any block of array memory would have to be owned exclusively by one ArrayBuilder, etc. just like with T[new].
Re: Revamping associative arrays
BCS wrote: Hello Chris Nicholson-Sauls, Andrei Alexandrescu wrote: Associative arrays are today quite problematic because they don't offer any true iteration. Furthermore, the .keys and .values properties create new arrays, which is wasteful. Another issue with associative arrays is that ++a[k] is hacked, which reflects a grave language limitation. That needs to be replaced with a true facility. Any other issues with AAs that you want to see fixed, and ideas guiding a redesign? Thanks, Andrei Idea: the .keys and .values properties, rather than creating arrays, could create iterable ranges with the smallest possible footprint, internally walking the tree structure. what will this do? foreach(key; aa.keys) if(Test(key)) aa.remove(key); Pre-cache a pointer to the next node in sequence; two pointers is still better than an arbitrarily long on-the-fly array. Its my understanding that AA trees do not automatically rebalance, so the sequence isn't going to (otherwise) change on a removal. End of the sequence means a null next pointer. For that matter: how common is looping over keys just to remove select ones versus other purposes in looping just the keys? -- Chris Nicholson-Sauls
Re: dmd support for IDEs + network GUI
On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Thanks for your interest and to the rest of the group for letting me go off topic like this! -- Adam D. Ruppe http://arsdnet.net
Re: 64-bit
Hello Nick, One more correction. The date I mention for Walter post is incorrect. It is in fact 11/08/2009 8:49 a.m. For us yanks that would be 08/11/2009 To Just Visting, no problem. Nick B
Re: DFL IDE Editor ?
Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add samhu.sa...@gmail.com in your list. Regards, Sam
Re: DFL IDE Editor ?
On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu samhudotsa...@gmail.com wrote: Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add samhu.sa...@gmail.com in your list. Regards, Sam DMD 2.035 didn't require any patches from DMD 2.034 for DFL. I've created a list with both you and dolive for future reference.
Re: The demise of T[new]
dsimcha wrote: == Quote from downs (default_357-l...@yahoo.de)'s article Walter Bright wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit of refining. The .length property of T[] would then become an rvalue only, not an lvalue, and ~= would no longer be allowed for T[]. We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. What do you think? I think ArrayBuilder can work almost entirely transparently provided the following conditions are met: 1) when trying to cat to an array, the first array automatically promotes to ArrayBuilder 2) Setting .length is, depending on new length, either a slice or a cat operation with the length difference. 2) ArrayBuilders implicitly cast to string. This should allow a syntax that is almost entirely identical to the one used in D1, aside from typeof(a~b).stringof :) Is this feasible in D2? Once you throw in all the implicit conversions to ArrayBuilder and having the core language know about ArrayBuilder, aren't you, for all practical purposes, implementing T[new] but calling it ArrayBuilder? Yes but changing the semantics of a library object is easier than changing the semantics of a language feature. Besides, I think the builder works differently internally than T[new], although I'm not sure - storing lists or trees of sub-arrays and concatenating them lazily? At least that's what I would do :p
Re: DFL IDE Editor ?
Robert Jacques дµ½: On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu samhudotsa...@gmail.com wrote: Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add samhu.sa...@gmail.com in your list. Regards, Sam DMD 2.035 didn't require any patches from DMD 2.034 for DFL. I've created a list with both you and dolive for future reference. I have received£¬ thank you very much ! but haven't include examples. I was updateed my e-mail-list,thank you ! dolive
Re: DFL IDE Editor ?
Robert Jacques дµ½: On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu samhudotsa...@gmail.com wrote: Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add samhu.sa...@gmail.com in your list. Regards, Sam DMD 2.035 didn't require any patches from DMD 2.034 for DFL. I've created a list with both you and dolive for future reference. Can you please be able to update to the dmd latest version of the Scintilla_DFL_Control http://wiki.dprogramming.com/Dfl/ScintillaControl thank you very much ! dolive
Re: The demise of T[new]
dsimcha wrote: The bugs in the current arrays are pretty nasty from a theoretical safety/purity point of view (esp. the one that's a hole in immutability), but are seldom run into in practice. We'd like to get D to the point where guarantees can be offered. This really sets it apart from C++, which offers no guarantees, and safety only happens if the programmer carefully follows convention. We need to do something about those nasty corner cases. Another issue is that D currently has two array types. Adding T[new] makes for 3 array types, and that starts to look like we couldn't figure out what we were doing. And lastly, the reason to make a type a built-in one is in order to offer substantial advantages over a library one. If a library one can do a good job, it is better to push it into the library. Making for a smaller core language makes it easier for people to get into D and feel comfortable with it. I was getting hard pressed to find significant advantages for T[new] over a library type. In particular, I find few uses for resizeable arrays as opposed to slices which are everywhere. When resizeable arrays are needed, they are usually isolated in one function, and when the function returns the resizeable array no longer needs to be resized - it can be converted to a slice type. Another interesting advantage to the library type for T[new] is it solves the problem of creating a safe immutable string. When the library T[new] is converted to an immutable string, the T[new] contents are removed - hence it won't be possible to create a mutable alias of an immutable string without a user-applied cast, which would not be allowed in safe mode.
Re: Sorry, I just love templates, AAs and mixins :)
Ellery Newcomer wrote:
grauzone wrote:
Saaa wrote:
public void addToAA(char[] var_name, KT, ET)(KT key, ET element)
{
mixin(ET.stringof~`[]* elements = key in `~var_name~`;`);
if( elements == null )
{
ET[] temp;
temp.length = 1;
temp[0] = element;
mixin(var_name~`[key] = temp;`);
}
else
{
(*elements).length = (*elements).length + 1;
(*elements)[(*elements).length-1] = element;
}
}
It's unreadable.
No it isn't. It's an obfusticated version of
if( key in var) var[key] ~= element;
else var[key] = [element];
No, it isn't. It's obfusticated version of the generic version of that code
:)
I always forget ~= and somehow [] with a single variable in it looks
strange, my bad!
So, thanks!
This is why I posted it in the first place; could you maybe look over DData
as well :)
I somehow like that I can tell the compiler precisely(mixins) how to
generate generic(templates) code..
but who wants to write that boring code? :)
Isn't your code slower because it always needs to search for the key twice
:P
Here is the new and improved version :
public void addToAAA(char[] var_name, KT, ET)(KT key, ET element)
{
mixin(ET.stringof~`[]* elements = key in `~var_name~`;`);
if( elements == null )
{
mixin(var_name~`[key] = [element];`);
}
else
{
(*elements) ~= element;
}
}
Re: Sorry, I just love templates, AAs and mixins :)
Ary Borenszweig wrote:
Saaa wrote:
public void addToAA(char[] var_name, KT, ET)(KT key, ET element)
{
mixin(ET.stringof~`[]* elements = key in `~var_name~`;`);
if( elements == null )
{
ET[] temp;
temp.length = 1;
temp[0] = element;
mixin(var_name~`[key] = temp;`);
Why `key`? Where's `key` defined?
Here: ...(KT key, ET element)
}
else
{
(*elements).length = (*elements).length + 1;
(*elements)[(*elements).length-1] = element;
I don't understand this. Key is not used.
That's because there is already a link to the key through elements.
}
}
And how do you use it? I tried to but I failed.
You need a AA defined like this:
BaseType[][KeyType] AAname;
addToAA!(AAname)(KeyType key, BaseType value);
Also passing a string as var_name is not nice. Isn't it better to write
something like:
char[int] x;
x.add(1, 'h');
?
The string is the actual variable name so I think that way doesn't work,
right?
Check the new version(shorter) in my other reply :D
Re: Sorry, I just love templates, AAs and mixins :)
Saaa wrote:
Ary Borenszweig wrote:
Saaa wrote:
public void addToAA(char[] var_name, KT, ET)(KT key, ET element)
{
mixin(ET.stringof~`[]* elements = key in `~var_name~`;`);
if( elements == null )
{
ET[] temp;
temp.length = 1;
temp[0] = element;
mixin(var_name~`[key] = temp;`);
Why `key`? Where's `key` defined?
Here: ...(KT key, ET element)
}
else
{
(*elements).length = (*elements).length + 1;
(*elements)[(*elements).length-1] = element;
I don't understand this. Key is not used.
That's because there is already a link to the key through elements.
}
}
And how do you use it? I tried to but I failed.
You need a AA defined like this:
BaseType[][KeyType] AAname;
addToAA!(AAname)(KeyType key, BaseType value);
Also passing a string as var_name is not nice. Isn't it better to write
something like:
char[int] x;
x.add(1, 'h');
?
The string is the actual variable name so I think that way doesn't work,
right?
Check the new version(shorter) in my other reply :D
This worked just now with DMD 2.035:
// BEGIN CODE
module test1;
import std .stdio ;
public void add ( AAA : E[][K], K, E ) ( ref AAA aa, K key, E[] elem ... ) {
if ( auto ptr = key in aa ) {
*ptr ~= elem;
}
else {
aa[ key ] = elem;
}
}
void main () {
int[][ char ] sandbox ;
sandbox.add( 'a', 1 );
sandbox.add( 'b', 1, 2 );
sandbox.add( 'c', 1 );
sandbox.add( 'a', 2, 3 );
foreach ( key, elems ; sandbox ) {
writeln(`[`, key, `] `, elems);
}
}
// END CODE
-- Chris Nicholson-Sauls
[Issue 2487] regexp .* fails to capture space in a greedy way
http://d.puremagic.com/issues/show_bug.cgi?id=2487 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||dsim...@yahoo.com Resolution||DUPLICATE --- Comment #1 from David Simcha dsim...@yahoo.com 2009-10-18 07:44:51 PDT --- *** This issue has been marked as a duplicate of issue 2108 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2108] regexp.d: The greedy dotstar isn't so greedy
http://d.puremagic.com/issues/show_bug.cgi?id=2108 David Simcha dsim...@yahoo.com changed: What|Removed |Added CC||swadena...@gmail.com --- Comment #1 from David Simcha dsim...@yahoo.com 2009-10-18 07:44:51 PDT --- *** Issue 2487 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 2973] std.math.pow(int, int), etc.
http://d.puremagic.com/issues/show_bug.cgi?id=2973 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Comment #7 from David Simcha dsim...@yahoo.com 2009-10-18 07:51:24 PDT --- Since I filed this one and I'm thoroughly convinced now that it's not necessary and noone else seems to want it, I'm resolving it as WONTFIX. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3416] New: Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416
Summary: Non-compilable template instantiation in is(typeof())
fails compilation
Product: D
Version: 2.035
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha samu...@voliacable.com 2009-10-18 11:25:00
PDT ---
template bar()
{
void bar()
{
a b; // invalid code
}
}
template foo()
{
enum foo = is(typeof(bar!()));
}
enum c = foo!();
test.d(19): Error: identifier 'a' is not defined
test.d(19): Error: a is used as a type
test.d(19): Error: variable Test.bar!().bar.b voids have no value
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Max Samukha samu...@voliacable.com changed: What|Removed |Added Severity|normal |blocker --- Comment #1 from Max Samukha samu...@voliacable.com 2009-10-18 11:56:17 PDT --- Looks like a blocker for QtD -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3417] New: std.stdio.File needs size
http://d.puremagic.com/issues/show_bug.cgi?id=3417
Summary: std.stdio.File needs size
Product: D
Version: 2.035
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-18 13:09:58 PDT ---
the std.stdio.File struct should have a way of getting the file size. If the
file is a standard stream or something, some convention like returning -1 could
be used. This would be trivial to implement (though I'm not saying this is
necessarily the best or most efficient way) by using something like:
try {
std.file.getSize(this.name);
} catch(FileException) { // A stream that isn't a real file.
return -1;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2973] std.math.pow(int, int), etc.
http://d.puremagic.com/issues/show_bug.cgi?id=2973 --- Comment #8 from Andrei Alexandrescu and...@metalanguage.com 2009-10-18 13:06:15 PDT --- (In reply to comment #7) Since I filed this one and I'm thoroughly convinced now that it's not necessary and noone else seems to want it, I'm resolving it as WONTFIX. Thanks for following through. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
