Re: Is This a Solution For the Const/Rebindable Issue?
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article What is the type of s.o? Hint, it can't be final, because final isn't part of the type. What is the type of s.o? If the type of s.o is T (let's say) and the type of s.o is not T*, then I think we have a problem. I just think it doesn't work. Maybe you can figure out a way it can, but I don't think it can be done without severe confusing semantics. -Steve Type of s.o: const(Object), like before. Can be reassigned. Type of s.o: Pointer to a const(Object)... yeah I think I finally see. x_x Gosh, that sucks... thanks for the explanation, I appreciate it. :) I'll see if I can figure out a way (though I doubt I can, lol)...
Re: Flag proposal [OT]
On 13/06/2011 02:31, Paul D. Anderson wrote: Alix Pexton Wrote: On 12/06/2011 16:11, Steven Schveighoffer wrote: On Sun, 12 Jun 2011 04:36:55 -0400, Alix Pexton alix.dot.pex...@gmail.dot.com wrote: On 12/06/2011 02:40, Steven Schveighoffer wrote: On Sat, 11 Jun 2011 13:04:47 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 6/11/11, Alix Pextonalix.dot.pex...@gmail.dot.com wrote: On 11/06/2011 06:18, Andrej Mitrovic wrote: We should rename Yes and No to Yay and Nay to make them alignable, and even more importantly to make us appear as old Englishmen! Yay and Nay are too similar looking, but luckily, Yay is not actually a old English word :) A more correct alternative would be Aye (pronounced the same as eye), which (along with Nay) is still used for some voting actions (such as councillors deciding where to go for lunch). I myself say it al least 20 times a day :) A... Oh damn, yay is what teenage girls would say, not old Englishmen. My bad, it really is Aye. :p You were phonetically right :) It's yea or nay. http://dictionary.cambridge.org/dictionary/british/yea-or-nay My son's most recent birthday (3 years old) was a farm-themed birthday, and we asked people to RSVP yay or neigh :P So I guess there's all kinds of kooky fun you can have with flags... -Steve Nope, its definitely Aye when used for voting, (at least it is round here) as in all those in favour, say aye, ayes to the right and the ayes have it. Maybe southerners say this yea word of which you speak, we don't hold with their strange customs in these parts ^^ I don't deny that aye is used frequently for voting. All I was saying is, the correct expression is yea or nay, not yay or nay. Andrej thought it was actually aye or nay, which I've never heard as an expression. I'm not sure it's used anymore, but it's definitely an expression that was used for voting (see my dictionary reference). -Steve True, yea-or-nay is quite a common, if old fashioned phrase, but yea on its own is exceptionally rare (to the point where I doubt ever hearing anyone make such a noise and mean it to indicate the affirmative). A... Then you must not have heard the King James Version of the Bible read aloud, or been to a Shakespeare play. Admittedly the KJV and Shakespeare's works don't count as modern English, but I doubt you've never heard such a noise! :-) p.s. The word appears 209 times in Shakespeare's plays. There's a website for everything! Aye, I did mean people using their own words and not someone else's. for such a prolific writer, 209 doesn't seem like a lot, and I can't help wondering how many times the bard used aye. Mind you, he was a southerner! A...
Re: Flag proposal
On Sun, 12 Jun 2011 14:59:57 -0400, Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:it1cvf$21d4$1...@digitalmars.com... It's the namespace pollution and the non-self-containedness of the function that's most troublesome. Also see Steve's point about methods. It's just untenable - to use the idiom with a class/struct method, you need to go all the way _outside_ of it an plant a symbol there. You can't put an enum in a class/struct? Yes, but then you have to qualify it with the name of the class/struct when using it. See Steve's post: http://www.digitalmars.com/webnews/newsgroups.php? art_group=digitalmars.Darticle_id=138281 -Lars
Does anyone actually use std.string.capwords or std.string.capitalize?
I have a hard time believing that std.string.capwords or std.string.captitalize are actually used much. It just doesn't seem to me like they would be generally useful functions. They're far too specific in what they do and aren't flexible enough. And if they're not pulling their own weight, then they should be removed from std.string. So, the question is: Is there anyone on the newsgroup here who actually uses std.string.capwords or std.string.capitalize? And if you do, do you use them often? - Jonathan M Davis
Re: Dynamic loading of shared libraries.
Steve Teale wrote:
Can DMD D2/Linux do this yet?
dmd can't do it yet. But if all you want is to link a against a shared
library you can try the following:
1. Create a shared library
$ gcc -m64 -fPIC -shared shared.c -o libshared.so
2. Building (without linking using dmd)
$ dmd -m64 -c dynamic.d -ofdynamic.o
3. Use gcc as linker
$ gcc -m64 dynamic.o /path/to//libphobos2.a -L. -lshared -lrt -o dynamic
4. Execute
$ ./dynamic
Hello from shared
I attached the files shared.c and dynamic.d, if you want to try
yourself.
Jens
#include stdio.h
void test() {
printf(Hello from shared\n);
}
extern(C) void test();
void main() {
test();
}
Re: Fixing the imaginary/complex mess
On 12/06/2011 23:37, bearophile wrote:
Andrei:
Don, instead of this fix, could be at best phase everything
built-in about complex out?
Two usages of complex numbers in the RosettaCode site.
Acommon place where you find complex numbers is to plot
Mandelbrot/Julia sets: http://rosettacode.org/wiki/Mandelbrot_set#D
import std.stdio, std.math;
void main() { enum maxIter = 1000; foreach (y; -39 .. 39) { foreach
(x; -39 .. 39) { auto c = y/40.0 - 0.5 + x/40.0i, z = 0.0 + 0.0i, i =
0; for (; i maxIter abs(z) 4; i++) z = z ^^ 2 + c; write(i ==
maxIter ? '#' : ' '); } writeln(); } }
Version using std.complex:
import std.stdio, std.complex;
void main() { enum maxIter = 1000; foreach (y; -39 .. 39) { foreach
(x; -39 .. 39) { auto c = Complex!double(y/40.0 - 0.5, x/40.0), z =
Complex!double(0, 0), i = 0; for (; i maxIter z.abs() 4; i++)
z = z ^^ 2 + c; write(i == maxIter ? '#' : ' '); } writeln(); } }
I think it's worth adding to std.complex module few examples of
usage, plus a complex() function so you are allowed to write (the
imaginary part defaults to zero if the real part is set to zero):
auto z = complex(5);
I seemed to think the plan for complex numbers was to do what happened
with associative arrays, that is, keep the language syntax, but have the
feature implemented in the library. Is this not the case?
--
Robert
http://octarineparrot.com/
Re: imports in functions
On 12/06/2011 22:15, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:
void test1()
{
import std.c.stdio;
printf(hello world\n);
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf(hello world\n);
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.
I did notice this - I think it's awesome. So many times when debugging
code I've attempted to write import std.stdio; in the function, then had
to move it away from the code I was debugging - of course this left a
stray import because I forgot about it :3
--
Robert
http://octarineparrot.com/
Re: Daniel Murphy (yebblies)
On 13/06/2011 03:22, Steven Schveighoffer wrote: I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! -Steve Indeed - I came home one day and saw ~100 new messages to the bug tracker newsgroup, thought someone had spammed the bug tracker or something. Turned out loads of old bugs were getting patched and closed! Needless to say I :D'd. I just hope Walter can cope with the ever-increasing size of the pull request list - I'd hate for development to stagnate due to there being too many pull requests. This said, the more the better! :D -- Robert http://octarineparrot.com/
Re: Fixing the imaginary/complex mess
On Mon, 13 Jun 2011 12:36:27 +0100, Robert Clipsham wrote:
On 12/06/2011 23:37, bearophile wrote:
Andrei:
Don, instead of this fix, could be at best phase everything built-in
about complex out?
Two usages of complex numbers in the RosettaCode site.
Acommon place where you find complex numbers is to plot
Mandelbrot/Julia sets: http://rosettacode.org/wiki/Mandelbrot_set#D
import std.stdio, std.math;
void main() { enum maxIter = 1000; foreach (y; -39 .. 39) { foreach (x;
-39 .. 39) { auto c = y/40.0 - 0.5 + x/40.0i, z = 0.0 + 0.0i, i = 0;
for (; i maxIter abs(z) 4; i++) z = z ^^ 2 + c; write(i ==
maxIter ? '#' : ' '); } writeln(); } }
Version using std.complex:
import std.stdio, std.complex;
void main() { enum maxIter = 1000; foreach (y; -39 .. 39) { foreach (x;
-39 .. 39) { auto c = Complex!double(y/40.0 - 0.5, x/40.0), z =
Complex!double(0, 0), i = 0; for (; i maxIter z.abs() 4; i++) z
= z ^^ 2 + c; write(i == maxIter ? '#' : ' '); } writeln(); } }
I think it's worth adding to std.complex module few examples of usage,
plus a complex() function so you are allowed to write (the imaginary
part defaults to zero if the real part is set to zero): auto z =
complex(5);
I seemed to think the plan for complex numbers was to do what happened
with associative arrays, that is, keep the language syntax, but have the
feature implemented in the library. Is this not the case?
That was my understanding as well, which is why I never added a complex()
helper function.
It is, however, my humble opinion that we should just get rid of the
complex literals. (Otherwise, std.complex would have to be moved into
druntime.)
-Lars
Re: Tokenized Strings -- Are Arbitrary Characters Valid?
All they are is passed through the tokeniser to ensure they lex as valid D (not parse). http://d-programming-language.org/lex.html A naked slash is not a valid token on its own, AFAIK, so it shouldn't work. But the other two are fine.
Re: Tokenized Strings -- Are Arbitrary Characters Valid?
On Mon, 13 Jun 2011 12:13:13 +, Bernard Helyer wrote: All they are is passed through the tokeniser to ensure they lex as valid D (not parse). http://d-programming-language.org/lex.html A naked slash is not a valid token on its own, AFAIK, so it shouldn't work. But the other two are fine. Back slash, rather.
Re: Tokenized Strings -- Are Arbitrary Characters Valid?
Actually, the \u stuff indicates a literal and not an actual token, so the only actually valid one is ''. Third time's the charm!
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
On 6/13/11 4:23 AM, Jonathan M Davis wrote: I have a hard time believing that std.string.capwords or std.string.captitalize are actually used much. It just doesn't seem to me like they would be generally useful functions. They're far too specific in what they do and aren't flexible enough. And if they're not pulling their own weight, then they should be removed from std.string. So, the question is: Is there anyone on the newsgroup here who actually uses std.string.capwords or std.string.capitalize? And if you do, do you use them often? - Jonathan M Davis These are not very D-like, and indeed so: they're part of Walter's experiment to include string functions from other string-savvy languages into Phobos1. These two particular functions are Python's: http://my.safaribooksonline.com/book/programming/python/0201616165/working-with-strings/ch10lev1sec2 It doesn't seem like the experiment was a success. To answer your question, I wouldn't shed a tear if these functions were gone. Andrei
Re: Dynamic loading of shared libraries.
On 6/13/11 4:27 AM, Jens Mueller wrote: Steve Teale wrote: Can DMD D2/Linux do this yet? dmd can't do it yet. But if all you want is to link a against a shared library you can try the following: 1. Create a shared library $ gcc -m64 -fPIC -shared shared.c -o libshared.so 2. Building (without linking using dmd) $ dmd -m64 -c dynamic.d -ofdynamic.o 3. Use gcc as linker $ gcc -m64 dynamic.o /path/to//libphobos2.a -L. -lshared -lrt -o dynamic 4. Execute $ ./dynamic Hello from shared I attached the files shared.c and dynamic.d, if you want to try yourself. Jens Jens, Two questions - first, what steps do we need to take to convince the linker call from within dmd to work as above? Second, how about the converse - loading a shared library from a program written in either C or D? Thanks, Andrei
Re: Fixing the imaginary/complex mess
On 6/13/11 6:36 AM, Robert Clipsham wrote: I seemed to think the plan for complex numbers was to do what happened with associative arrays, that is, keep the language syntax, but have the feature implemented in the library. Is this not the case? No, the current vision is to completely replace complex with library artifacts. Walter wants to keep the i postfix as a hack, but I think that's completely unnecessary. A complex() convenience function should be useful. If anyone has the time, please create a pull request. It should never automatically create Complex with an integral type, as bearophile mentioned. For the rare cases where complex is needed with integrals, it should be fine to use Complex!int etc. directly. Andrei
Re: Daniel Murphy (yebblies)
On 6/13/11 6:43 AM, Robert Clipsham wrote: On 13/06/2011 03:22, Steven Schveighoffer wrote: I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! -Steve Indeed - I came home one day and saw ~100 new messages to the bug tracker newsgroup, thought someone had spammed the bug tracker or something. Turned out loads of old bugs were getting patched and closed! Needless to say I :D'd. I just hope Walter can cope with the ever-increasing size of the pull request list - I'd hate for development to stagnate due to there being too many pull requests. This said, the more the better! :D Walter is continuously working on improving speed of pull request integration. The bottleneck right now is the compiler test suite, which takes hours to run. Andrei
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
Jonathan M Davis wrote: Is there anyone on the newsgroup here who actually uses std.string.capwords or std.string.capitalize? And if you do, do you use them often? I use capitalize from time to time. It seems to work well enough. Is there really a need to break people's code every other day just because a random function doesn't do everything perfectly? Fixing bugs is one thing, but removing functionality is another. At some point, Phobos devs need to realize that people actually *use* D.
Re: Daniel Murphy (yebblies)
On 13/06/2011 14:39, Andrei Alexandrescu wrote: Walter is continuously working on improving speed of pull request integration. The bottleneck right now is the compiler test suite, which takes hours to run. Andrei Is there some way we could speed this up? Obviously it can't be run for multiple pull requests at once, as they requests could affect each other, so it'll need a third run if they're run at the same time. Is there some way we could work around that? What hardware does it take hours to run on? Could a donation of some faster hardware help? Perhaps something like Google does could be useful to decrease the amount of time the suite takes (see my post about continuous integration at Google not too long ago). -- Robert http://octarineparrot.com/
Re: Dynamic loading of shared libraries.
On 13/06/2011 14:32, Andrei Alexandrescu wrote: Two questions - first, what steps do we need to take to convince the linker call from within dmd to work as above? Second, how about the converse - loading a shared library from a program written in either C or D? I was under the impression that dmd couldn't produce shared libraries in its current state - doesn't its output clobber the PIC register or something when compiling with -fPIC? http://d.puremagic.com/issues/show_bug.cgi?id=4583 Thanks, Andrei -- Robert http://octarineparrot.com/
Re: Daniel Murphy (yebblies)
Robert Clipsham wrote: On 13/06/2011 14:39, Andrei Alexandrescu wrote: Walter is continuously working on improving speed of pull request integration. The bottleneck right now is the compiler test suite, which takes hours to run. Andrei Is there some way we could speed this up? Obviously it can't be run for multiple pull requests at once, as they requests could affect each other, so it'll need a third run if they're run at the same time. Is there some way we could work around that? What hardware does it take hours to run on? Could a donation of some faster hardware help? Perhaps something like Google does could be useful to decrease the amount of time the suite takes (see my post about continuous integration at Google not too long ago). -- Robert http://octarineparrot.com/ I think the easiest way to speed it up would be to run it distributed on multiple PCs of different devs or trusted members of the community. Timon
Re: Improvements to std.string
I vote for the changes. They are better name for newbies like me. On Mon, Jun 13, 2011 at 9:29 AM, Adam D. Ruppe destructiona...@gmail.com wrote: Jonathan M Davis wrote: Would it be better to rename toStringz to toCString when fixing it I think it should stay just how it is: toStringz, with a lowercase z. The reason is a stringz is actually a proper name of sorts - the z at the end isn't a new word, but part of the first one. At least that's the way it was in assembly! Also, it ain't broke. I've sometimes gotten tolower wrong due to case. I've never made a mistake on toStringz. I'd be surprised if anyone has.
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
On 6/13/11, Adam D. Ruppe destructiona...@gmail.com wrote: Jonathan M Davis wrote: Is there anyone on the newsgroup here who actually uses std.string.capwords or std.string.capitalize? And if you do, do you use them often? I use capitalize from time to time. It seems to work well enough. Is there really a need to break people's code every other day just because a random function doesn't do everything perfectly? Fixing bugs is one thing, but removing functionality is another. At some point, Phobos devs need to realize that people actually *use* D. And some of them probably don't even post here! I'm not sure what removing these two functions buys anyone?
Re: Fixing the imaginary/complex mess
On Mon, 13 Jun 2011 08:36:32 -0500, Andrei Alexandrescu wrote: On 6/13/11 6:36 AM, Robert Clipsham wrote: I seemed to think the plan for complex numbers was to do what happened with associative arrays, that is, keep the language syntax, but have the feature implemented in the library. Is this not the case? No, the current vision is to completely replace complex with library artifacts. Walter wants to keep the i postfix as a hack, but I think that's completely unnecessary. A complex() convenience function should be useful. If anyone has the time, please create a pull request. It should never automatically create Complex with an integral type, as bearophile mentioned. For the rare cases where complex is needed with integrals, it should be fine to use Complex!int etc. directly. Sure, I'll add complex(). Regarding Complex!int: I have explicitly restricted Complex to floating- point types. Here is a message I sent to the Phobos mailing list, explaining why: http://lists.puremagic.com/pipermail/phobos/2010-April/000286.html See also Don's reply to that message, it really drives the point home: http://lists.puremagic.com/pipermail/phobos/2010-April/000287.html -Lars
safe
How safe is safe D to run on your computer as if it is a client application. Let's say you want something like this. 1) The source is compared to the local one on the current disk. If the remote version is newer the new version is downloaded. 2) The source gets compiled and then executed in safe D but with only a subset of phobos that can not alter anything permanent on the disk. (as if it is a javascript client application). Like a replacement for HTML5 and javascript. ...or not suitable? I'm going to eat now.
Broken link
On the main page: http://www.d-programming-language.org/index.html Click on Howtos in the left menu. That takes you to the first howto: http://www.d-programming-language.org/windows.html Then the Howto link called PortÂing to 64 Bits is broken: http://www.d-programming-language.org/32-64-portability.html Preliminary testing showed that the same Porting to 64 Bits is broken on all of the howto pages. -Kai Meyer
Re: Dynamic loading of shared libraries.
Andrei Alexandrescu wrote: On 6/13/11 4:27 AM, Jens Mueller wrote: Steve Teale wrote: Can DMD D2/Linux do this yet? dmd can't do it yet. But if all you want is to link a against a shared library you can try the following: 1. Create a shared library $ gcc -m64 -fPIC -shared shared.c -o libshared.so 2. Building (without linking using dmd) $ dmd -m64 -c dynamic.d -ofdynamic.o 3. Use gcc as linker $ gcc -m64 dynamic.o /path/to//libphobos2.a -L. -lshared -lrt -o dynamic 4. Execute $ ./dynamic Hello from shared I attached the files shared.c and dynamic.d, if you want to try yourself. Jens Jens, Two questions - first, what steps do we need to take to convince the linker call from within dmd to work as above? Never thought about that. Just tried. $ dmd -m64 dynamic.o /path/to/libphobos2.a -L-L. -L-lshared -L-lrt -ofdynamic works. Second, how about the converse - loading a shared library from a program written in either C or D? Don't know exactly what you mean. As far as I know dmd is not able to generate shared libraries. Is that your question? Jens
Re: safe
sclytrack Wrote: How safe is safe D to run on your computer as if it is a client application. Let's say you want something like this. 1) The source is compared to the local one on the current disk. If the remote version is newer the new version is downloaded. 2) The source gets compiled and then executed in safe D but with only a subset of phobos that can not alter anything permanent on the disk. (as if it is a javascript client application). Like a replacement for HTML5 and javascript. ...or not suitable? I'm going to eat now. SafeD is about memory corruption and not security. You'd have to provide your own system security through a framework and system administration.
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
On 2011-06-13 07:07, Adam D. Ruppe wrote: Jonathan M Davis wrote: Is there anyone on the newsgroup here who actually uses std.string.capwords or std.string.capitalize? And if you do, do you use them often? I use capitalize from time to time. It seems to work well enough. Is there really a need to break people's code every other day just because a random function doesn't do everything perfectly? Fixing bugs is one thing, but removing functionality is another. At some point, Phobos devs need to realize that people actually *use* D. Which is why I'm asking rather than just yanking them. Just because _I_ don't find them useful doesn't mean that others don't. If people actually use them, then there's reason to keep them. But there are a number of functions in std.string which at least _look_ like their of limited usefulness, and if they're really not used, then they shouldn't be there. However, if they really _are_ used, then getting rid of them would be a bad idea. So, I'm asking whether anyone uses them. - Jonathan M Davis
Re: Fixing the imaginary/complex mess
On Mon, 13 Jun 2011 14:51:52 +, Lars T. Kyllingstad wrote: On Mon, 13 Jun 2011 08:36:32 -0500, Andrei Alexandrescu wrote: A complex() convenience function should be useful. If anyone has the time, please create a pull request. [...] Sure, I'll add complex(). As promised: https://github.com/D-Programming-Language/phobos/pull/103 -Lars
Re: safe
On 2011-06-13 08:02, sclytrack wrote: How safe is safe D to run on your computer as if it is a client application. Let's say you want something like this. 1) The source is compared to the local one on the current disk. If the remote version is newer the new version is downloaded. 2) The source gets compiled and then executed in safe D but with only a subset of phobos that can not alter anything permanent on the disk. (as if it is a javascript client application). Like a replacement for HTML5 and javascript. ...or not suitable? I'm going to eat now. D is a systems language. You can do pretty much anything with it. SafeD is a subset of D which restricts certain types of operatons which are not necessarily memory safe, thereby avoiding certain types of bugs. When it says safe, it means _memory_ safe, and that's it. It doesn't really say much about what you can or can't do with the language. Sure, it's probably impossible to make a kernel with just SafeD, but D is not sitting in a sandbox like a web browser. It can do whatever it gets told to do. If anything, D is intended to be a replacement for C++, not HTML5 and javascript. It's a _systems_ language. - Jonathan M Davis
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
It looks like people have reimplemented capitalize in some libs:
D:\dev\lib\D\boxen\src\xf\utils\CT.d:25:pragma(ctfe) char[]
capitalize(char[] name) {
D:\dev\lib\D\boxen\src\xf\xpose2\MiniD.d:51:pragma(ctfe) private
char[] capitalizeFirst(char[] str) {
D:\dev\lib\D\boxen\src\xf\xpose2\MiniD.d:62:return set ~
capitalizeFirst(name);
D:\dev\lib\D\boxen\src\xf\xpose2\Utils.d:25:pragma(ctfe) char[]
capitalize(char[] name) {
And I found a match here:
D:\dev\lib\D\enticesource\plugins.d:2317: s =
std.string.capitalize(s);
I've found no match for capwords though.
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
On 2011-06-13 08:50, Andrej Mitrovic wrote:
It looks like people have reimplemented capitalize in some libs:
D:\dev\lib\D\boxen\src\xf\utils\CT.d:25:pragma(ctfe) char[]
capitalize(char[] name) {
D:\dev\lib\D\boxen\src\xf\xpose2\MiniD.d:51:pragma(ctfe) private
char[] capitalizeFirst(char[] str) {
D:\dev\lib\D\boxen\src\xf\xpose2\MiniD.d:62: return set ~
capitalizeFirst(name);
D:\dev\lib\D\boxen\src\xf\xpose2\Utils.d:25:pragma(ctfe) char[]
capitalize(char[] name) {
And I found a match here:
D:\dev\lib\D\enticesource\plugins.d:2317: s =
std.string.capitalize(s);
I've found no match for capwords though.
Well, capwords is not something you're likely to find implementations of by
grepping, since the name has a good chance of being different. But regardless,
I find it much easier to believe that someone is using capitalize than
capwords, particularly since capitalize is a building block of capwords.
- Jonathan M Davis
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
On 2011-06-13 08:56, Jonathan M Davis wrote:
On 2011-06-13 08:50, Andrej Mitrovic wrote:
It looks like people have reimplemented capitalize in some libs:
D:\dev\lib\D\boxen\src\xf\utils\CT.d:25:pragma(ctfe) char[]
capitalize(char[] name) {
D:\dev\lib\D\boxen\src\xf\xpose2\MiniD.d:51:pragma(ctfe) private
char[] capitalizeFirst(char[] str) {
D:\dev\lib\D\boxen\src\xf\xpose2\MiniD.d:62:return set ~
capitalizeFirst(name);
D:\dev\lib\D\boxen\src\xf\xpose2\Utils.d:25:pragma(ctfe) char[]
capitalize(char[] name) {
And I found a match here:
D:\dev\lib\D\enticesource\plugins.d:2317: s =
std.string.capitalize(s);
I've found no match for capwords though.
Well, capwords is not something you're likely to find implementations of by
grepping, since the name has a good chance of being different. But
regardless, I find it much easier to believe that someone is using
capitalize than capwords, particularly since capitalize is a building
block of capwords.
In any case, thanks for finding some evidence that capitalize is actually
being used.
- Jonathan M Davis
Re: Dynamic loading of shared libraries.
On 6/13/11 10:33 AM, Jens Mueller wrote: Andrei Alexandrescu wrote: On 6/13/11 4:27 AM, Jens Mueller wrote: Steve Teale wrote: Can DMD D2/Linux do this yet? dmd can't do it yet. But if all you want is to link a against a shared library you can try the following: 1. Create a shared library $ gcc -m64 -fPIC -shared shared.c -o libshared.so 2. Building (without linking using dmd) $ dmd -m64 -c dynamic.d -ofdynamic.o 3. Use gcc as linker $ gcc -m64 dynamic.o /path/to//libphobos2.a -L. -lshared -lrt -o dynamic 4. Execute $ ./dynamic Hello from shared I attached the files shared.c and dynamic.d, if you want to try yourself. Jens Jens, Two questions - first, what steps do we need to take to convince the linker call from within dmd to work as above? Never thought about that. Just tried. $ dmd -m64 dynamic.o /path/to/libphobos2.a -L-L. -L-lshared -L-lrt -ofdynamic works. Great. Wonder why the path to Phobos is still needed - does using -L preclude all implicit uses of it? Second, how about the converse - loading a shared library from a program written in either C or D? Don't know exactly what you mean. As far as I know dmd is not able to generate shared libraries. Is that your question? Yah, I was wondering if it's just PIC generation or something extra. Andrei
Re: Daniel Murphy (yebblies)
On 6/13/11 9:12 AM, Robert Clipsham wrote: On 13/06/2011 14:39, Andrei Alexandrescu wrote: Walter is continuously working on improving speed of pull request integration. The bottleneck right now is the compiler test suite, which takes hours to run. Andrei Is there some way we could speed this up? Obviously it can't be run for multiple pull requests at once, as they requests could affect each other, so it'll need a third run if they're run at the same time. Is there some way we could work around that? Actually I suggested him to optimistically integrate several requests at once and then run the test suite. Only if the suite fails, fall back on integrating one at a time. What hardware does it take hours to run on? Could a donation of some faster hardware help? Perhaps something like Google does could be useful to decrease the amount of time the suite takes (see my post about continuous integration at Google not too long ago). Walter? Andrei
Re: Does anyone actually use std.string.capwords or std.string.capitalize?
On 6/13/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Well, capwords is not something you're likely to find implementations of by grepping, since the name has a good chance of being different. But regardless, I find it much easier to believe that someone is using capitalize than capwords, particularly since capitalize is a building block of capwords. Agreed. You can already use a mix of split() and capitalize(), so capwords might be a good candidate to remove.
Re: Daniel Murphy (yebblies)
How do you run the DMD unittests, is it just make -fwin32.mak debdmd ? I'd like to test it on my hardware.
Re: safe
sclytrack: How safe is safe D to run on your computer as if it is a client application. Walter (I think) has decided to call it Safe D, but a better name is memory safe D because it describes better that it gives only a specialized kind of safety. Bye, bearophile
Re: Does anyone actually use std.string.capwords or
Jonathan M Davis: But there are a number of functions in std.string which at least _look_ like their of limited usefulness, and if they're really not used, then they shouldn't be there. What functions? (I think in Python I have used capitalize only once so far.) Bye, bearophile
Re: Fixing the imaginary/complex mess
Andrei: Walter wants to keep the i postfix as a hack, but I think that's completely unnecessary. Before deciding I'd like to know the rationale to keep it. In principle I like handy complex number literals. In practice I don't use them often enough... Another note: I'd like std.math.abs to perform what std.complex.Complex!T.abs does. So I will be able to use it functionally (currently std.math.abs is able to digest built-in complex numbers too): alias Complex!double C; C[] a = [C(1,2), C(2,4)]; auto m = map!abs(a); Bye, bearophile
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Andrej Mitrovic:
Hey I've just realized something (well, it was in the docs, doh!), we
can use already use switch case; to fallthrough to the next label
without explicitly using goto:
void main()
{
int x = 2;
switch (x)
{
case 2:
goto case; // goto case 3;
break;
case 3:
This is good to have, but I don't find this syntax easy to understand,
readable, natural. A @fallthrough is much more explicit, but it's a very
specialized thing.
Bye,
bearophile
Re: safe
sclytrack wrote: Like a replacement for HTML5 and javascript. You *could* make this work, but the language itself won't help you. There's two approaches: a) Run the code on your server and only output the display on the client's computer. Like an X11 application. http://en.wikipedia.org/wiki/X11 b) Have the operating system limit the D application. It's not really possible to filter out malicious D code. Someone could always call an operating system function directly, even marking it @trusted so it works in safe mode. But, if you configure the operating system the right way, you can make all those potentially nasty calls unavailable. Put an operating system level limit on file access, put up a network firewall, limit it's CPU time, etc. Most the newer HTML web browsers are doing this in addition to javascript. The same principles can be used on almost any program.
Re: Flag proposal
Andrei:
If we all get convinced that named parameters are worth it,
I think this is not going to happen because some people (two?) don't want this
feature.
I am for it, if it's well implemented. The reordering is one important part of
this feature.
An optional sub-feature is a way to deprecate argument names. Thankfully in D
there is already the deprecated keyword; a first idea:
void foo(int deprecated(y) x) {}
Or:
void foo(int deprecated{y} x) {}
Bye,
bearophile
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Yeah I'd rather have it be something like goto next, but then this steals another keyword. Anyway you can always be explicit with your gotos if you want readability.
Re: TempAlloc Overhaul
Walter: bearophile, some way in which you are replying causes Thunderbird to lose track of the thread you are replying to, and starts a new thread. I know... and I am sorry (The cause is me that I want to the web interface, and because it is buggy, it breaks the threads very easily). Bye, bearophile
Re: Dynamic loading of shared libraries.
Andrei Alexandrescu wrote: On 6/13/11 10:33 AM, Jens Mueller wrote: Andrei Alexandrescu wrote: On 6/13/11 4:27 AM, Jens Mueller wrote: Steve Teale wrote: Can DMD D2/Linux do this yet? dmd can't do it yet. But if all you want is to link a against a shared library you can try the following: 1. Create a shared library $ gcc -m64 -fPIC -shared shared.c -o libshared.so 2. Building (without linking using dmd) $ dmd -m64 -c dynamic.d -ofdynamic.o 3. Use gcc as linker $ gcc -m64 dynamic.o /path/to//libphobos2.a -L. -lshared -lrt -o dynamic 4. Execute $ ./dynamic Hello from shared I attached the files shared.c and dynamic.d, if you want to try yourself. Jens Jens, Two questions - first, what steps do we need to take to convince the linker call from within dmd to work as above? Never thought about that. Just tried. $ dmd -m64 dynamic.o /path/to/libphobos2.a -L-L. -L-lshared -L-lrt -ofdynamic works. Great. Wonder why the path to Phobos is still needed - does using -L preclude all implicit uses of it? No. You're right. It works without the path to Phobos. Second, how about the converse - loading a shared library from a program written in either C or D? Don't know exactly what you mean. As far as I know dmd is not able to generate shared libraries. Is that your question? Yah, I was wondering if it's just PIC generation or something extra. There have been some posts regarding support for shared libraries. On top of my head there we're at least 5 things that need to be done to get it working. $ dmd -m64 -L-shared shared.d -oflibshared.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 I do not fully understand the error. But I believe there is something wrong with dmd generating PIC. Jens
Re: Struct Interface Implementation?
On 2011-06-13 06:21:47 +0300, Mehrdad said: Yeah I was referring to something similar to what C# has (aside from the lack of boxing). On 6/12/2011 6:46 PM, Andrei Alexandrescu wrote: On 6/12/11 8:28 PM, Jonathan M Davis wrote: They aren't virtual. For an interface to work, it has to be virtual. structs are value types, not reference types. They have no virtual table and have no polymorphism. Why would they need to be virtual? They obviously aren't in C#, but they still work pretty well (e.g. foreach loops work with ListT.Enumerator, which is a struct but which can be treated as the IEnumeratorT interface), right? In C# compiler can do stuff that you are not allowed to do, such as autoboxing structs in objects to allow Interface usage, calling Object methods or some magic duck typing. In most cases it devirtualizes calls, so there is no overhead in boxing. He must be referring to nominal conformance. It's been discussed many times. There are important disadvantages (e.g. you can't implement a type alias) but there are advantages too. Ultimately we never got around to it. Andrei Haha ok, that's a good reason in its own way, thanks. :)
Re: Does anyone actually use std.string.capwords or
On 2011-06-13 09:55, bearophile wrote: Jonathan M Davis: But there are a number of functions in std.string which at least _look_ like their of limited usefulness, and if they're really not used, then they shouldn't be there. What functions? (I think in Python I have used capitalize only once so far.) At the moment, I'm just asking about capitalize and capwords. The usefulness (or lack thereof) of various std.string functions has been discussed before, and I think that that it's clear that some of the less basic ones may need to either be removed or revamped, but they need to be looked at individually. But at the moment, capitalize and capwords are the only functions which I'm concerned with. - Jonathan M Davis
Re: safe
On 2011-06-13 09:57, bearophile wrote: sclytrack: How safe is safe D to run on your computer as if it is a client application. Walter (I think) has decided to call it Safe D, but a better name is memory safe D because it describes better that it gives only a specialized kind of safety. _All_ safety is only a specialized kind of safety. It would be impossible to use the word safe in all of its contexts in a computer language. For instance, you could write a virus in D, and _that_ could certainly be considered unsafe. - Jonathan M Davis
Re: Daniel Murphy (yebblies)
On Mon, 2011-06-13 at 14:41 +, Timon Gehr wrote: Robert Clipsham wrote: On 13/06/2011 14:39, Andrei Alexandrescu wrote: Walter is continuously working on improving speed of pull request integration. The bottleneck right now is the compiler test suite, which takes hours to run. Andrei Is there some way we could speed this up? Obviously it can't be run for multiple pull requests at once, as they requests could affect each other, so it'll need a third run if they're run at the same time. Is there some way we could work around that? What hardware does it take hours to run on? Could a donation of some faster hardware help? Perhaps something like Google does could be useful to decrease the amount of time the suite takes (see my post about continuous integration at Google not too long ago). -- Robert http://octarineparrot.com/ I think the easiest way to speed it up would be to run it distributed on multiple PCs of different devs or trusted members of the community. Isn't this what Jenkins (aka Hudson) and Buildbot are good for. People can offer up machines that are permanently connected as slaves and then it is a question of programming up the central master to spawn runs of tests of appropriate feature branches? Or am I missing something about the DMD situation? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Daniel Murphy (yebblies)
On 6/12/2011 7:22 PM, Steven Schveighoffer wrote: I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! I agree. Other prolific dmd contributors to getting the backlog of old compiler bugs addressed are 9rnsr (Hara Kenji), kennytm, and Don Clugston. Several others are also stepping up with significant contributions https://github.com/D-Programming-Language/dmd/pulls It's an embarrassment of riches. It makes it abundantly clear that the best thing we ever did for improving the quality of dmd was put it on github.
fiber local storage
Not available yet, but Intel announced support for manipulating FS and GS in user mode. Protection for fiber local storage is one use case. http://software.intel.com/file/36945
Re: Daniel Murphy (yebblies)
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vwzsvfkyeav7ka@localhost.localdomain... I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! I'm having lots of fun! I was originally just looking through bugzilla for interesting bugs to fix, but now I'm about a third of the way through a quick (!) pass, after a couple of days on it.
any way to prevent overriding of .init ?
Right now there are lot of Phobos functionality that fully expects
A.init to return just that - a default initialized value of type A.
Now consider:
struct A
{
int i;
void init(int K)
{
//blah
}
}
Then:
map!a.i([A(1), A(2), A(3)]);
for me explodes with :
std\algorithm.d(382): Error: function test.A.init (int K) is not
callable using argument types ()
std\algorithm.d(382): Error: expected 1 function arguments, not 0
due to this line in std.algorithm:
alias typeof(_fun(.ElementType!R.init)) ElementType;
Any way to circumvent this name lookup oddity and get to built-in property?
If there is, shouldn't we use it throughout Phobos?
The issue is not a theoretical one - it severely limits usability of my
pull request (not posted because of this) that makes dirEntries return
proper InputRange of DirEntry . Namely, DirEntry happen to define just
such a function (init).
--
Dmitry Olshansky
Re: Daniel Murphy (yebblies)
I am interested in more proper language features to implement. Github is good tool for contributing to D community. Kenji Hara (9rnsr) 2011/6/14 Walter Bright newshou...@digitalmars.com: On 6/12/2011 7:22 PM, Steven Schveighoffer wrote: I just want to say, I'm thoroughly impressed by the speed and effort Daniel Murphy is putting into fixing bugs with the compiler. Not to mention, he is closing already fixed bugs (an important, but tedious task). Bravo, Daniel! I agree. Other prolific dmd contributors to getting the backlog of old compiler bugs addressed are 9rnsr (Hara Kenji), kennytm, and Don Clugston. Several others are also stepping up with significant contributions https://github.com/D-Programming-Language/dmd/pulls It's an embarrassment of riches. It makes it abundantly clear that the best thing we ever did for improving the quality of dmd was put it on github.
Re: imports in functions
I'm having some fun with this.
import std.array;
void main()
{
with (namespace!(std.stdio std.algorithm std.range))
{
auto squares = map!(a * a)([2, 4, 6]);
writeln(squares);
}
}
template namespace(string x)
{
mixin(namespaceImpl(x));
}
string namespaceImpl(string x)
{
string result;
auto mods = split(x);
foreach (val; mods)
{
result ~= import ~ val ~ ;;
}
return result;
}
Re: imports in functions
Btw, it's disappointing that I can't call split with a separator at compile-time: enum result = split(bla, bla); // ok enum result = split(bla, bla, ,); // nope
Re: any way to prevent overriding of .init ?
I'm having the same issue with a COM interface that happens to define an init method. I've used a COM object inside a struct and used the 'alias this' trick to forward all calls, but for init I had to create a special 'initialize' method in the struct that would call the COM object's init method explicitly.
Re: any way to prevent overriding of .init ?
On 2011-06-13 12:50, Dmitry Olshansky wrote:
Right now there are lot of Phobos functionality that fully expects
A.init to return just that - a default initialized value of type A.
Now consider:
struct A
{
int i;
void init(int K)
{
//blah
}
}
Then:
map!a.i([A(1), A(2), A(3)]);
for me explodes with :
std\algorithm.d(382): Error: function test.A.init (int K) is not
callable using argument types ()
std\algorithm.d(382): Error: expected 1 function arguments, not 0
due to this line in std.algorithm:
alias typeof(_fun(.ElementType!R.init)) ElementType;
Any way to circumvent this name lookup oddity and get to built-in property?
If there is, shouldn't we use it throughout Phobos?
The issue is not a theoretical one - it severely limits usability of my
pull request (not posted because of this) that makes dirEntries return
proper InputRange of DirEntry . Namely, DirEntry happen to define just
such a function (init).
If init is causing a problem, get rid of it. It's scheduled for deprecation
anyway, and it arguably never should have been called by anyone other than
std.file in the first place.
- Jonathan M Davis
Re: any way to prevent overriding of .init ?
On 14.06.2011 0:03, Jonathan M Davis wrote:
On 2011-06-13 12:50, Dmitry Olshansky wrote:
Right now there are lot of Phobos functionality that fully expects
A.init to return just that - a default initialized value of type A.
Now consider:
struct A
{
int i;
void init(int K)
{
//blah
}
}
Then:
map!a.i([A(1), A(2), A(3)]);
for me explodes with :
std\algorithm.d(382): Error: function test.A.init (int K) is not
callable using argument types ()
std\algorithm.d(382): Error: expected 1 function arguments, not 0
due to this line in std.algorithm:
alias typeof(_fun(.ElementType!R.init)) ElementType;
Any way to circumvent this name lookup oddity and get to built-in property?
If there is, shouldn't we use it throughout Phobos?
The issue is not a theoretical one - it severely limits usability of my
pull request (not posted because of this) that makes dirEntries return
proper InputRange of DirEntry . Namely, DirEntry happen to define just
such a function (init).
If init is causing a problem, get rid of it. It's scheduled for deprecation
anyway, and it arguably never should have been called by anyone other than
std.file in the first place.
Well, I that what I'm was thinking to do as 'right here, right now'
solution.
Now taking into account that it wasn't documented before I'll just kill it.
Still, the general issue remains.
--
Dmitry Olshansky
Re: any way to prevent overriding of .init ?
On 2011-06-13 13:06, Dmitry Olshansky wrote:
On 14.06.2011 0:03, Jonathan M Davis wrote:
On 2011-06-13 12:50, Dmitry Olshansky wrote:
Right now there are lot of Phobos functionality that fully expects
A.init to return just that - a default initialized value of type A.
Now consider:
struct A
{
int i;
void init(int K)
{
//blah
}
}
Then:
map!a.i([A(1), A(2), A(3)]);
for me explodes with :
std\algorithm.d(382): Error: function test.A.init (int K) is not
callable using argument types ()
std\algorithm.d(382): Error: expected 1 function arguments, not 0
due to this line in std.algorithm:
alias typeof(_fun(.ElementType!R.init)) ElementType;
Any way to circumvent this name lookup oddity and get to built-in
property? If there is, shouldn't we use it throughout Phobos?
The issue is not a theoretical one - it severely limits usability of my
pull request (not posted because of this) that makes dirEntries return
proper InputRange of DirEntry . Namely, DirEntry happen to define just
such a function (init).
If init is causing a problem, get rid of it. It's scheduled for
deprecation anyway, and it arguably never should have been called by
anyone other than std.file in the first place.
Well, I that what I'm was thinking to do as 'right here, right now'
solution.
Now taking into account that it wasn't documented before I'll just kill it.
Still, the general issue remains.
True. And I would argue that it should probably be illegal to declare a
function with the name init which is not a free function. Maybe that would be
unacceptable for some reason, but it seems to me that it would solve the
problem quite cleanly.
- Jonathan M Davis
Re: imports in functions
On Jun 14, 11 03:55, Andrej Mitrovic wrote: Btw, it's disappointing that I can't call split with a separator at compile-time: enum result = split(bla, bla); // ok enum result = split(bla, bla, ,); // nope That's due to (at least) http://d.puremagic.com/issues/show_bug.cgi?id=4047.
Re: Flag proposal
bearophile bearophileh...@lycos.com wrote in message
news:it5gqj$a1g$1...@digitalmars.com...
Andrei:
If we all get convinced that named parameters are worth it,
I think this is not going to happen because some people (two?) don't want
this feature.
I am for it, if it's well implemented. The reordering is one important
part of this feature.
An optional sub-feature is a way to deprecate argument names. Thankfully
in D there is already the deprecated keyword; a first idea:
void foo(int deprecated(y) x) {}
Or:
void foo(int deprecated{y} x) {}
I like it!
Re: Flag proposal
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:it3ne2$1g2f$1...@digitalmars.com...
On 6/12/11 2:19 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:it32j8$2gfq$1...@digitalmars.com...
On 6/12/11 1:45 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:it1c0f$1uup$1...@digitalmars.com...
On 06/11/2011 03:52 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.orgwrote in
message
news:it07ni$1pvj$1...@digitalmars.com...
Anyway, that was the first thing grep yes std/* found. Let's see
the
next one:
/**
Specifies whether the output of certain algorithm is desired in
sorted
format.
*/
enum SortOutput {
no, /// Don't sort output
yes, /// Sort output
}
This already is very unpleasant because certain is as imprecise as
it
gets. Plus one for Flag, I hope you agree.
Flag -= 1
s/output of certain algorithm/output of an algorithm/ += 1
That one-word doc change makes it all perfectly clear.
Not at all. The typo in the original text must have confused you: it
should be certain algorithms because SortOutput is used in four
distinct
algorithms (one of which has two overloads). Grep std/algorithm.d.
Flag += 2
Not that I consider quibbling over small English wording differences a
major
thing, but I fail to see how:
Specifies whether the output of an algorithm is desired in sorted
format.
is significantly different from:
Specifies whether the output of certain algorithms are desired in
sorted
format.
In either case, I don't see anything problematically imprecise.
Still means I need to jump back and forth in the documentation.
And you don't like the ///ditto suggestion for handling that?
That actually does help, but not for enums used by more than one function.
The other issues remain too.
I would think that an enum used by more than one function *should* be listed
separately.
Re: Flag proposal
On 6/13/11 4:02 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:it3ne2$1g2f$1...@digitalmars.com... That actually does help, but not for enums used by more than one function. The other issues remain too. I would think that an enum used by more than one function *should* be listed separately. Actually, not necessarily, if the definition is self explanatory. By the same argument a named argument with the same name and meaning in several functions doesn't necessarily have to be defined separately. Andrei
Re: Flag proposal
On 6/13/11 4:02 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:it3ne2$1g2f$1...@digitalmars.com... That actually does help, but not for enums used by more than one function. The other issues remain too. I would think that an enum used by more than one function *should* be listed separately. Actually, not necessarily, if the definition is self explanatory. By the same argument a named argument with the same name and meaning in several functions doesn't necessarily have to be defined separately. Andrei What about just not documenting the enum itself? This elegantly resolves the 'certain' vs. 'an' debate too :o). Timon
Re: safe
Hi Adam, Were you in the past not working on a Gui lib that did an a) type of thing? IFAIR, The app ran on the server, the gui was on the client. Someone could (via a client) connect to the app on the server, but have it displayed locally? ~ filgood On 13/06/2011 18:15, Adam D. Ruppe wrote: sclytrack wrote: Like a replacement for HTML5 and javascript. You *could* make this work, but the language itself won't help you. There's two approaches: a) Run the code on your server and only output the display on the client's computer. Like an X11 application. http://en.wikipedia.org/wiki/X11 b) Have the operating system limit the D application. It's not really possible to filter out malicious D code. Someone could always call an operating system function directly, even marking it @trusted so it works in safe mode. But, if you configure the operating system the right way, you can make all those potentially nasty calls unavailable. Put an operating system level limit on file access, put up a network firewall, limit it's CPU time, etc. Most the newer HTML web browsers are doing this in addition to javascript. The same principles can be used on almost any program.
Re: safe
Were you in the past not working on a Gui lib that did an a) type of thing? Yes. It's still something I'm very slowly working on, but with my web app based day job taking up so much time it hasn't had any new code for months now... But yeah, it'd run on a server and you display it locally. You can also disconnect and reconnect to the application from another computer without needing to restart the app. The same api is also usable for a local desktop app or as a javascript web app. I've written a little bit for each part of it, but haven't actually *finished* any of it...
turtles features (Was: Flag proposal)
Andrei Alexandrescu wrote:
module my_module;
void fun()
{
import std.random;
return uniform(0, 100);
}
int gun()
{
import std.stdio;
writeln(fun());
}
This module won't compile in today's D, but not for a matter of
principles; it's just a random limitation of the language. (It does work
if you import from within a class or struct.) You can insert most
declarations in a scope, so the ones you can't insert are just awkward
exceptions, unless there's a good reason to actively disable them. Any
code should work if you just wrap another scope around it.
//void main(){
immutable a = b;
immutable b = 1;
int foo(int n){
if(n==1) return 1;
return 1+bar(n);
}
int bar(int n){
if(n1) return foo(3*n+1);
return foo(n/2);
}
//}
Will this be fixed too?
Timon
Re: Dynamic loading of shared libraries.
On Mon, 13 Jun 2011, Jens Mueller wrote: There have been some posts regarding support for shared libraries. On top of my head there we're at least 5 things that need to be done to get it working. $ dmd -m64 -L-shared shared.d -oflibshared.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 I do not fully understand the error. But I believe there is something wrong with dmd generating PIC. Jens When building a shared library, you must build with -fPIC. That's likely not sufficient to get it actually fully working with dmd. so: dmd -m64 -fPIC -L-shared shared.d -oflibshared.so That said, combining not-well-tested .so support with 64 bit is a good way to discover new bugs, so go for it! :) Later, Brad
Re: turtles features (Was: Flag proposal)
Timon Gehr:
Will this be fixed too?
Mutually recursive inner functions are not so common, and there is a
workaround, making one of them a delegate defined before.
But what about this?
auto foo()()
out(result) {
} body {
return 0;
}
void main() {
foo();
}
test.d(1): Error: function test.foo!().foo post conditions are not supported if
the return type is inferred
test.d(7): Error: template instance test.foo!() error instantiating
test.d(7): Error: forward reference to inferred return type of function call foo
This is a common problem for my code, is it possible to fix (support) this? (In
functional-style code auto return values are sometimes almost necessary).
Bye,
bearophile
Rename std.ctype to std.ascii?
std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters). std.uni, on the other hand, operates on characters just like std.ctype does, but it extends its charter to unicode characters (e.g. it has isUniUpper which _does_ work on unicode characters, unlike std.ctype's isupper). The thing is that aside from those familiar with C/C++, most programmers are likely to find the module name ctype to be rather uniformative. If they're looking for something like isdigit, they're not terribly likely to go looking at std.ctype first. And I'm not sure that std.ascii will be all that much more obvious to them, but it fits in much better with std.uni. std.ascii gets the character functions which operate only on ASCII characters, and std.uni gets the character functions which operate on unicode characters in addition to ASCII characters. I don't think that the change of module name is enough of an improvement to merit changing the name just because ctype is arguably bad. However, as it turns out, _no_ function in std.ctype is properly camelcased, and many of them return int instead of bool (which the C functions they're modeled after do but which is not particularly D-like and can cause problems when you actual _need_ them to return bool). And it has been made very clear in past discussions in this newsgroup that the consensus is that we prefer that Phobos functions follow Phobos' naming conventions (which means camelcasing) rather than matching the casing of functions in other languages. So, all of the functions in std.ctype need to be renamed. I now have a pull request which creates properly camelcased versions of all of them ( https://github.com/D-Programming-Language/phobos/pull/101 ). The thing is though that because _every_ function in std.ctype is renamed, the cost of renaming the entire module (as far as people updating their code to use functions such as isDigit instead of isdigit goes) is essentially the same if as just renaming the functions in-place. In either case, the old functions will go through the full deprecation process before they're actually gone, so no one's code will suddenly break because of the changes, but any code that uses the old functions will eventually have to be change to use the properly named ones. And since the cost to making those changes is essentially the same whether we replace the whole std.ctype module or whether we replace all of its functions, I'm wondering whether it would be worthwhile to take this opportunity to rename std.ctype? I don't think that the name change is enough of an improvement to do it if it's going to break everyone's code, but given that fixing all of its functions gives us a perfect opportunity to rename it at no additional cost, I feel that the question should be posed. Should we rename std.ctype to std.ascii? Or should we just keep the old name, which is familiar to C programmers? - Jonathan M Davis
Re: Flag proposal
On Mon, 13 Jun 2011 20:19:15 +0300, bearophile bearophileh...@lycos.com wrote: Andrei: If we all get convinced that named parameters are worth it, I think this is not going to happen because some people (two?) don't want this feature. I think they worth it and it is the right time to talk extensively why people think they don't. And reasoning should not be about its failure or success in another language, we better have our own rules. IMO named arguments in D at least should do: - Reordering (since we got default parameters, even better) - It is enabled only if we have access to the function declaration. - In a function call we either use named arguments for all the non-default arguments or call it with the usual syntax. No hybrid stuff, no confusion. fun(int a, int b, int c=3) fun(1, 2, 3) // fine - current fun(1, 2) // fine - current fun(a:1, b:3, c:5) // fine fun(a:1, b:3) // fine fun(b:1, c:3, a:5) // fine fun(b:1, a:3) // fine fun(b:1) // error fun(c:1) // error fun(2, b:1) // error fun(2, c:1) // error fun(2, c:2, 3) // error Thanks.
Re: Rename std.ctype to std.ascii?
On Mon, Jun 13, 2011 at 10:28 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters). std.uni, on the other hand, operates on characters just like std.ctype does, but it extends its charter to unicode characters (e.g. it has isUniUpper which _does_ work on unicode characters, unlike std.ctype's isupper). The thing is that aside from those familiar with C/C++, most programmers are likely to find the module name ctype to be rather uniformative. If they're looking for something like isdigit, they're not terribly likely to go looking at std.ctype first. And I'm not sure that std.ascii will be all that much more obvious to them, but it fits in much better with std.uni. std.ascii gets the character functions which operate only on ASCII characters, and std.uni gets the character functions which operate on unicode characters in addition to ASCII characters. I don't think that the change of module name is enough of an improvement to merit changing the name just because ctype is arguably bad. However, as it turns out, _no_ function in std.ctype is properly camelcased, and many of them return int instead of bool (which the C functions they're modeled after do but which is not particularly D-like and can cause problems when you actual _need_ them to return bool). And it has been made very clear in past discussions in this newsgroup that the consensus is that we prefer that Phobos functions follow Phobos' naming conventions (which means camelcasing) rather than matching the casing of functions in other languages. So, all of the functions in std.ctype need to be renamed. I now have a pull request which creates properly camelcased versions of all of them ( https://github.com/D-Programming-Language/phobos/pull/101 ). The thing is though that because _every_ function in std.ctype is renamed, the cost of renaming the entire module (as far as people updating their code to use functions such as isDigit instead of isdigit goes) is essentially the same if as just renaming the functions in-place. In either case, the old functions will go through the full deprecation process before they're actually gone, so no one's code will suddenly break because of the changes, but any code that uses the old functions will eventually have to be change to use the properly named ones. And since the cost to making those changes is essentially the same whether we replace the whole std.ctype module or whether we replace all of its functions, I'm wondering whether it would be worthwhile to take this opportunity to rename std.ctype? I don't think that the name change is enough of an improvement to do it if it's going to break everyone's code, but given that fixing all of its functions gives us a perfect opportunity to rename it at no additional cost, I feel that the question should be posed. Should we rename std.ctype to std.ascii? Or should we just keep the old name, which is familiar to C programmers? - Jonathan M Davis or deprecate std.ctype and create a new std.ascii.
Re: Flag proposal
On 6/14/11 8:36 AM, so wrote: On Mon, 13 Jun 2011 20:19:15 +0300, bearophile bearophileh...@lycos.com wrote: Andrei: If we all get convinced that named parameters are worth it, I think this is not going to happen because some people (two?) don't want this feature. I think they worth it and it is the right time to talk extensively why people think they don't. And reasoning should not be about its failure or success in another language, we better have our own rules. IMO named arguments in D at least should do: - Reordering (since we got default parameters, even better) - It is enabled only if we have access to the function declaration. - In a function call we either use named arguments for all the non-default arguments or call it with the usual syntax. No hybrid stuff, no confusion. A different rule can be: - Named arguments come last. - Any previous arguments match the order. fun(int a, int b, int c=3) fun(1, 2, 3) // fine - current fun(1, 2) // fine - current fun(a:1, b:3, c:5) // fine fun(a:1, b:3) // fine fun(b:1, c:3, a:5) // fine fun(b:1, a:3) // fine fun(b:1) // error // error: missing a fun(c:1) // error // error: missing a and b fun(2, b:1) // error // ok, a is 2, b is 1, c is 3 fun(2, c:1) // error // error: missing b fun(2, c:2, 3) // error // error, 3 after named arguments
Re: Rename std.ctype to std.ascii?
On 2011-06-13 18:43, Jose Armando Garcia wrote: On Mon, Jun 13, 2011 at 10:28 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters). std.uni, on the other hand, operates on characters just like std.ctype does, but it extends its charter to unicode characters (e.g. it has isUniUpper which _does_ work on unicode characters, unlike std.ctype's isupper). The thing is that aside from those familiar with C/C++, most programmers are likely to find the module name ctype to be rather uniformative. If they're looking for something like isdigit, they're not terribly likely to go looking at std.ctype first. And I'm not sure that std.ascii will be all that much more obvious to them, but it fits in much better with std.uni. std.ascii gets the character functions which operate only on ASCII characters, and std.uni gets the character functions which operate on unicode characters in addition to ASCII characters. I don't think that the change of module name is enough of an improvement to merit changing the name just because ctype is arguably bad. However, as it turns out, _no_ function in std.ctype is properly camelcased, and many of them return int instead of bool (which the C functions they're modeled after do but which is not particularly D-like and can cause problems when you actual _need_ them to return bool). And it has been made very clear in past discussions in this newsgroup that the consensus is that we prefer that Phobos functions follow Phobos' naming conventions (which means camelcasing) rather than matching the casing of functions in other languages. So, all of the functions in std.ctype need to be renamed. I now have a pull request which creates properly camelcased versions of all of them ( https://github.com/D-Programming-Language/phobos/pull/101 ). The thing is though that because _every_ function in std.ctype is renamed, the cost of renaming the entire module (as far as people updating their code to use functions such as isDigit instead of isdigit goes) is essentially the same if as just renaming the functions in-place. In either case, the old functions will go through the full deprecation process before they're actually gone, so no one's code will suddenly break because of the changes, but any code that uses the old functions will eventually have to be change to use the properly named ones. And since the cost to making those changes is essentially the same whether we replace the whole std.ctype module or whether we replace all of its functions, I'm wondering whether it would be worthwhile to take this opportunity to rename std.ctype? I don't think that the name change is enough of an improvement to do it if it's going to break everyone's code, but given that fixing all of its functions gives us a perfect opportunity to rename it at no additional cost, I feel that the question should be posed. Should we rename std.ctype to std.ascii? Or should we just keep the old name, which is familiar to C programmers? - Jonathan M Davis or deprecate std.ctype and create a new std.ascii. Well, yes. That's what would be happening. All of the old functions would be in std.ctype and put on the deprecation path, while the new std.ascii would have the new, properly camelcased functions in it. But what that's effectively doing is renaming std.ctype to std.ascii. It's just that std.ctype will stick around with its old functions until it's gone through the full deprecation cycle. - Jonathan M Davis
Re: Flag proposal
On Tue, 14 Jun 2011 04:46:54 +0300, Ary Manzana a...@esperanto.org.ar wrote: On 6/14/11 8:36 AM, so wrote: On Mon, 13 Jun 2011 20:19:15 +0300, bearophile bearophileh...@lycos.com wrote: Andrei: If we all get convinced that named parameters are worth it, I think this is not going to happen because some people (two?) don't want this feature. I think they worth it and it is the right time to talk extensively why people think they don't. And reasoning should not be about its failure or success in another language, we better have our own rules. IMO named arguments in D at least should do: - Reordering (since we got default parameters, even better) - It is enabled only if we have access to the function declaration. - In a function call we either use named arguments for all the non-default arguments or call it with the usual syntax. No hybrid stuff, no confusion. A different rule can be: - Named arguments come last. - Any previous arguments match the order. IMO the main that makes NAs confusing is allowing hybrid calls. I don't think allowing reordering then introducing two new rules on ordering is a good idea.
Re: Rename std.ctype to std.ascii?
I'm all for it. I've never liked ctype, and I got lost trying to find ascii functions since I didn't know where to look. The first time I saw ctype I thought it was a collection of C type aliases.. heh.
Re: Rename std.ctype to std.ascii?
Come to think of it, I think I had a note in a todo somewhere that said post a feature request to change ctype to ascii. It's a good standard name.
Re: imports in functions
Walter, it looks like this addition inadvertently fixes the issue of
DLLs not linkable due to Phobos imports.
I've had this DLL (alongside with dllmodule.d which had initialization
calls inside DLLMain):
module EdrLib;
import std.utf;
pragma(lib, gdi32.lib);
pragma(lib, comdlg32.lib);
import win32.windef;
import win32.wingdi;
export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
SIZE size ;
GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
(prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}
The header file produced from this would cause any client code which
imports the header to look for ModuleInitZ, which wouldn't exist in
the generated import library since it's an import library and not a
static library.
But, if I move the phobos import inside the EdrCenterText function:
export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
import std.utf;
SIZE size ;
GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
(prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}
Then it works. My related bug report about this (and its complicated
to read due to various misunderstanding on my part) is
http://d.puremagic.com/issues/show_bug.cgi?id=6019.
But it's great that there's an actual workaround now!
Re: imports in functions
On 6/13/2011 8:28 PM, Andrej Mitrovic wrote:
Walter, it looks like this addition inadvertently fixes the issue of
DLLs not linkable due to Phobos imports.
I've had this DLL (alongside with dllmodule.d which had initialization
calls inside DLLMain):
module EdrLib;
import std.utf;
pragma(lib, gdi32.lib);
pragma(lib, comdlg32.lib);
import win32.windef;
import win32.wingdi;
export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
SIZE size ;
GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
(prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}
The header file produced from this would cause any client code which
imports the header to look for ModuleInitZ, which wouldn't exist in
the generated import library since it's an import library and not a
static library.
But, if I move the phobos import inside the EdrCenterText function:
export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
import std.utf;
SIZE size ;
GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
(prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}
Then it works. My related bug report about this (and its complicated
to read due to various misunderstanding on my part) is
http://d.puremagic.com/issues/show_bug.cgi?id=6019.
But it's great that there's an actual workaround now!
This makes me think that there's actually a bug in the function-local imports.
I'm guessing they don't run module-level
ctors and dtors for the imported modules. Would you mind putting together a
test case to check?
Thanks,
Brad
Re: imports in functions
When I add module ctors/dtors, I get the ModuleInfoZ shenanigans again.
Re: imports in functions
And they do run, I've tested it in a non-DLL example.
Re: imports in functions
I'm guessing this is what you're after: http://codepad.org/TCtG68Fw http://codepad.org/65GBDjPS rdmd main.d shared ctor! ctor! foo.test dtor! shared dtor!
Re: imports in functions
Should DLLs even have module ctors/dtors? I think this is what DLLMain's DLL_PROCESS_ATTACH, DLL_THREAD_ATTACH and their detach counterparts are for.
Re: imports in functions
On 6/13/2011 8:48 PM, Andrej Mitrovic wrote:
I'm guessing this is what you're after:
http://codepad.org/TCtG68Fw
http://codepad.org/65GBDjPS
rdmd main.d
shared ctor!
ctor!
foo.test
dtor!
shared dtor!
Actually, not what I was thinking. I was thinking something like this:
file 1:
import std.stdio; // or inside this, not what I'm testing.
static this()
{
writeln(foo);
}
file 2:
void main()
{
import file1;
}
Re: imports in functions
Well it seems to work fine. :)
Re: safe
== Quote from filgood (filg...@somewhere.net)'s article Hi Adam, Were you in the past not working on a Gui lib that did an a) type of thing? IFAIR, The app ran on the server, the gui was on the client. Someone could (via a client) connect to the app on the server, but have it displayed locally? There is the gdk broadway backend. Applications run on the server. The result is displayed in the browser http://blogs.gnome.org/alexl/ You can even display a browser in a browser. For running the javascript apps on the client side there is qooxdoo. Communicates with the server with mostly JSON RPC with the same source policy (I've wasted a lot of time on that one) http://qooxdoo.org/ And for running binaries on the client side with some form of shielding there is Google native client. http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/ ~ filgood On 13/06/2011 18:15, Adam D. Ruppe wrote: sclytrack wrote: Like a replacement for HTML5 and javascript. You *could* make this work, but the language itself won't help you. There's two approaches: a) Run the code on your server and only output the display on the client's computer. Like an X11 application. http://en.wikipedia.org/wiki/X11 b) Have the operating system limit the D application. It's not really possible to filter out malicious D code. Someone could always call an operating system function directly, even marking it @trusted so it works in safe mode. But, if you configure the operating system the right way, you can make all those potentially nasty calls unavailable. Put an operating system level limit on file access, put up a network firewall, limit it's CPU time, etc. Most the newer HTML web browsers are doing this in addition to javascript. The same principles can be used on almost any program.
What remains to be done for D2?
Hi, Can someone please explain what needs to be done (other than fixing the plethora of bugs) to call D2 final? And if someone can provide an approximate estimate of when? I would like to switch majority of my programming from C++ to D2 but the number of bugs and uncertainty of how exactly will non-garbage collected classes work makes me a bit cautious.(could someone please explain too) Also, how much slower is D2 compared to C++? Will D2 final have comparable performance? Thanks Petr Janda
Re: What remains to be done for D2?
Petr Janda janda.p...@gmail.com wrote in message news:it6npg$6l8$1...@digitalmars.com... Also, how much slower is D2 compared to C++? Will D2 final have comparable performance? D2 already has comparable performance to C++. And various things like built-in slices and good metaprogramming make it easier to write fast code: http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/ http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-with-rapidxml/ http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/ http://www.semitwist.com/articles/EfficientAndFlexible/SinglePage/
Re: What remains to be done for D2?
Petr Janda janda.p...@gmail.com wrote in message news:it6npg$6l8$1...@digitalmars.com... Hi, Can someone please explain what needs to be done (other than fixing the plethora of bugs) to call D2 final? And if someone can provide an approximate estimate of when? I already find D2, even with occasional bugs, to be *far* better than dealing with C++. And no language is ever final unless it's a dead language. D2's already ready for production use IMO, and many people are already using it professionally. uncertainty of how exactly will non-garbage collected classes work makes me a bit cautious.(could someone please explain too) Basically you can use either structs (which are not heap-allocated unless you specifically ask for them to be) or you use emplace. For emplace, you allocate your own chunk of memory however you want, and then pass it to the emplace function in Phobos which will construct your object right there in place instead of allocating new GC'ed memory. Somebody else can explain the details better than I can, I've never actually used emplace myself.
Re: Flag proposal
so s...@so.so wrote in message news:op.vw1msqy0mpw3zg@so-pc... On Tue, 14 Jun 2011 04:46:54 +0300, Ary Manzana a...@esperanto.org.ar wrote: On 6/14/11 8:36 AM, so wrote: On Mon, 13 Jun 2011 20:19:15 +0300, bearophile bearophileh...@lycos.com wrote: Andrei: If we all get convinced that named parameters are worth it, I think this is not going to happen because some people (two?) don't want this feature. I think they worth it and it is the right time to talk extensively why people think they don't. And reasoning should not be about its failure or success in another language, we better have our own rules. IMO named arguments in D at least should do: - Reordering (since we got default parameters, even better) - It is enabled only if we have access to the function declaration. - In a function call we either use named arguments for all the non-default arguments or call it with the usual syntax. No hybrid stuff, no confusion. A different rule can be: - Named arguments come last. - Any previous arguments match the order. IMO the main that makes NAs confusing is allowing hybrid calls. I don't think allowing reordering then introducing two new rules on ordering is a good idea. I think Ary's suggestion is very simple and easy to understand. Hybrid calls are *only* confusing when an unnamed parameter comes after a named one.
Re: What remains to be done for D2?
Am 14.06.2011 07:24, schrieb Nick Sabalausky: Petr Janda janda.p...@gmail.com wrote in message news:it6npg$6l8$1...@digitalmars.com... Hi, Can someone please explain what needs to be done (other than fixing the plethora of bugs) to call D2 final? And if someone can provide an approximate estimate of when? I already find D2, even with occasional bugs, to be *far* better than dealing with C++. And no language is ever final unless it's a dead language. D2's already ready for production use IMO, and many people are already using it professionally. uncertainty of how exactly will non-garbage collected classes work makes me a bit cautious.(could someone please explain too) Basically you can use either structs (which are not heap-allocated unless you specifically ask for them to be) or you use emplace. For emplace, you allocate your own chunk of memory however you want, and then pass it to the emplace function in Phobos which will construct your object right there in place instead of allocating new GC'ed memory. Somebody else can explain the details better than I can, I've never actually used emplace myself. Example of an custom (de)allocator for class-objects (using C malloc/free and emplace()): http://pastebin.com/9Qgf3vc7 Cheers, - Daniel
Re: Rename std.ctype to std.ascii?
Jonathan M Davis jmdavisp...@gmx.com wrote: std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters). What is your definition for ASCII character? Most of the ctype.h functions (or macros) are locale dependent, see setlocale() and locale.h. And there is the wctype.h, too. While the C standardized ways of doing things might not be most appropriate approach in D domain, we must not base our design decisions on deficient analysis. I just want this text uppercase is one of the hardest things in the _world_. The problem is not just the header or package naming. -- Jouko
Re: Clear big AAs
useo:
Is there anything I forgot to consider?
If the key and values are primitive values or structs of primitive
values then you may try another AA implementation that doesn't use
the GC.
Bye,
bearophile
I tried some different implementations and I also reduced the size of
my arrays without any success :(. It always drops down to 1 FPS for 1
second and after that it runs for some seconds normal until next 1
FPS-second.
I also tried to do the work within a separate thread, also without
success. My current code looks like:
toRender.clear();
toRender = null;
for (int y = pFromY; y pToY y pTiles.length; y++) {
for (int x = pFromX; x pToX x pTiles[y].length; x++) {
toRender[pTiles[y][x].texture] ~= pTiles[y][x];
}
}
toRender is my AA which contains the textures as key (instances of my
class Texture) and the tiles (position of them) as values. When I
remove the first two lines (clear and set null) it doesn't drops down
to 1 FPS, it runs normal.
I hope anyone know a solution :)
introspection woes...
Trying to play with introspection.
trying o, for a given object, to check its property by name.
Experimenting with the function below.
1. it doesn't compile! mi.name() seems to be a problem?
2. match is always null! even though I pass the name of an existing property
and / or field!
===
Object getelement(Object o, string aname)
{
if (!o)
return null;
auto ci = o.classinfo;
writefln(class: %s, ci.name);
auto match = ci.getMembers(aname);
foreach(mi ; ci.getMembers(null))
{
writefln(%s . %s, ci.name, mi.name());
}
//writefln(match: %s, match);
return o;
}
==
Re: Object
I see mm Thanks for the info! Jonathan M Davis wrote in message news:mailman.866.1307943671.14074.digitalmars-d-le...@puremagic.com... Object is not currently const-correct: http://d.puremagic.com/issues/show_bug.cgi?id=1824 As a result, a number of basic functions do not currently work with const objects. So, making opEquals const means that it's not going to work. It sucks, but until Object is fixed to be const-correct, that's the way it goes.
Re: Is it reasonable to learn D
Let's learn together then! :P http://galador.net/codeblog/?tag=/D While my blog post are only about setting up the environment so far.. I have delved in the code for 2 weeks now! (Although I had some day off (work and programing) in Darwin) I'm right into it now, should have a new blog post soon! About programing this time! My verdict: it's frustrating yes. But D has a couple of advantages and 2 that you might like: - D has event / delegate, just like C# (and unlike C++, or maybe C++ has them, (it has method pointer, right!?) but it's not taken advantage of!) - the above point is probably what makes the C++ GUI so... difficult. Whereas I found a GUI API for D just like WinForm! (DGui!) In short summary I found these cool things: VisualD 0.3.24 (plugin for programing from Visual Studio) http://www.dsource.org/projects/visuald VisualD NOTE: (system tweaks)(required) : edit sc.ini http://www.dsource.org/projects/visuald/wiki/KnownIssues#Librarysearchpathnotpassedtolinker DGui 02052011 (WinForm like API) http://code.google.com/p/dgui/ Doost (r88) (serialization) http://www.dsource.org/projects/doost Windows API r371 http://dsource.org/projects/bindings/wiki/WindowsApi Fabian wrote in message news:islvgf$1b61$1...@digitalmars.com... Dear D Community, is it reasonable to learn D? I've found a lot of good points for D but I've found a lot of negative points too. I believe that I needn't to list all the point for D but I want to give a few examples against learning D I've read in some German and English boards: - The D compiler has only bad code optimization - There are no maintained GUI libraries - The development of the compiler is very slow - Only a small community = no real German community So I ask you - Is it reasonable to learn D? I'm looking forward to your answers. Greetings Fabian PS: If you want to contact me you are allowed to write an Email to me. contact-...@freemail.de
introspection woes (2)
trying to learn introspection, I have this simple test method:
===
static void dumpelement(Object o)
{
if (!o)
return;
auto ci = o.classinfo;
foreach(mi ; ci.getMembers(null))
{
writefln(%s . %s, ci.name, mi.name());
}
}
==
However it fails to compile with the following error: (any ideas?)
===
main.d(57): Error: function object.MemberInfo.name () is not callable using
argument types () const
Building Debug\dtest.exe failed!
WindowsAPI Binding - Linker Errors
Hello! I've been test programming win32 applications recently, and since the phobos win32 library is so limited, I decided to download and test the WindowsAPI Binding (http://www.dsource.org/projects/bindings/wiki/WindowsApi). Using the latest snapshot (as of this writing) I receive the following linker errors when I compile: Error 42: Symbol Undefined _D5win328winerror12MAKE_HRESULTFbkkZi (MAKE_HRESULT is undefined). These are my imports: win32.mmsystem, win32.windef, win32.winuser, win32.wingdi and win32.directx.d3d9. The problem lies within the DirectX module. If I do not import it, there are no errors. I've taken the d3d9.lib and d3dx9.lib from the DirectX SDK and used coffimplib and the linked to them, without success. These are the libraries I am linking to: gdi32.lib, winmm.lib and d3d9.lib. Any theories why MAKE_HRESULT is undefined? Have I forgotten to link to something?
