Re: Bullet Physics in D
On Wednesday, 22 August 2012 at 05:30:17 UTC, BLM768 wrote: A while back, I tried porting Bullet Physics to D, and I decided to resume work on it. I've got the code I've ported so far at sourceforge.net/projects/bulletd. I wrote most of the code when I was early in my D learning experience, so it's fairly rough, and it's nowhere near complete (a rough line count analysis gave well under 5%), but it's a start. If anyone wants to help, it would be appreciated. My main reasons for making a port rather than a binding are that SWIG doesn't like nested classes, so it's useless for Bullet, and I wanted to integrate it with the GC. D and C++ are close enough that getting a port of at least the basic features shouldn't take too long; I'm not sure what I'll end up doing about the OpenCL options and such. You could make use of the OpenCL bindings for D. https://github.com/Trass3r/cl4d -- Paulo
Re: Bullet Physics in D
You could make use of the OpenCL bindings for D. https://github.com/Trass3r/cl4d -- Paulo That should work. I'll probably focus on the OpenCL stuff last, but I'll keep that in mind; it should help make the porting a little easier.
Re: Bullet Physics in D
Am 22.08.2012 07:30, schrieb BLM768: A while back, I tried porting Bullet Physics to D, and I decided to resume work on it. This is great! I've got the code I've ported so far at sourceforge.net/projects/bulletd. I wrote most of the code when I was early in my D learning experience, so it's fairly rough, and it's nowhere near complete (a rough line count analysis gave well under 5%), but it's a start. If anyone wants to help, it would be appreciated. What do you think of moving to github? It makes contributing a lot easier.
Re: Bullet Physics in D
What do you think of moving to github? It makes contributing a lot easier. I'm fine with that. I should have it moved within an hour.
Re: Bullet Physics in D
On Wednesday, 22 August 2012 at 18:39:40 UTC, BLM768 wrote: What do you think of moving to github? It makes contributing a lot easier. I'm fine with that. I should have it moved within an hour. OK; got it moved. It's at https://github.com/blm768/BulletD.
Re: Antti-Ville Tuuainen Passes GSoC Final Evaluation
On Tuesday, 21 August 2012 at 13:15:49 UTC, dsimcha wrote: Congratulations, Antti-Ville! This project creates a better implementation of precise GC heap scanning than anything that's been created so far for D. The goal is to eventually integrate it into standard D distributions. Great! I've been pretty much out of touch with the GSoC projects this summers, as I had a rather intense exam session at university – are there any progress reports/blog posts with actual numbers in them? David
Re: Bullet Physics in D
I'm trying to figure out the allocation model that the port should use. Bullet normally provides its own allocators for efficiency, but I've been trying to integrate the port with the GC where it's practical. Does anyone have suggestions on the best approach? I'm not too familiar with Bullet's allocation system, so I should probably research that...
Re: Bullet Physics in D
On Wednesday, 22 August 2012 at 20:26:37 UTC, BLM768 wrote: I'm trying to figure out the allocation model that the port should use. Bullet normally provides its own allocators for efficiency, but I've been trying to integrate the port with the GC where it's practical. Does anyone have suggestions on the best approach? I'm not too familiar with Bullet's allocation system, so I should probably research that... I've used Bullet in a professional capacity, and I'd hesitant to force the GC on your users. I'd port their allocators and supply implementations that map to malloc or the GC and let users that have their own heap implementations map them to those. There are a couple of reasons for this: 1) Most large game engines/simulations probably already have several types of custom allocators that they'd like to map bullet allocations to. 2) GC is not necessarily the best model for keeping track of physics data. Usually, physics objects are tied to their game entity counterparts and should be cleaned up as soon as those go away. This ownership is mostly unambiguous, so its not much of a burden to remember to clean up the physics objects. I used ref counting when I set up my company's implementation but even that is probably not necessary.
Re: Bullet Physics in D
I've used Bullet in a professional capacity, and I'd hesitant to force the GC on your users. I'd port their allocators and supply implementations that map to malloc or the GC and let users that have their own heap implementations map them to those. There are a couple of reasons for this: 1) Most large game engines/simulations probably already have several types of custom allocators that they'd like to map bullet allocations to. 2) GC is not necessarily the best model for keeping track of physics data. Usually, physics objects are tied to their game entity counterparts and should be cleaned up as soon as those go away. This ownership is mostly unambiguous, so its not much of a burden to remember to clean up the physics objects. I used ref counting when I set up my company's implementation but even that is probably not necessary. I'll probably mainly keep Bullet's system in place, then. I might at least replace Bullet's C++ new and/or malloc with GC allocations, but I'm undecided on that.
Re: Bullet Physics in D
On 08/22/2012 09:06 PM, BLM768 wrote: I've used Bullet in a professional capacity, and I'd hesitant to force the GC on your users. I'd port their allocators and supply implementations that map to malloc or the GC and let users that have their own heap implementations map them to those. There are a couple of reasons for this: 1) Most large game engines/simulations probably already have several types of custom allocators that they'd like to map bullet allocations to. 2) GC is not necessarily the best model for keeping track of physics data. Usually, physics objects are tied to their game entity counterparts and should be cleaned up as soon as those go away. This ownership is mostly unambiguous, so its not much of a burden to remember to clean up the physics objects. I used ref counting when I set up my company's implementation but even that is probably not necessary. I'll probably mainly keep Bullet's system in place, then. I might at least replace Bullet's C++ new and/or malloc with GC allocations, but I'm undecided on that. I don't know much about this library, but what you're saying sounds like a good strategy. Things in the D ecosystem tend to be safe by default (use GC by default in this case) but allow for optimizations or low level tweaking (allow users to supply their own allocators if they want to).
Re: Antti-Ville Tuuainen Passes GSoC Final Evaluation
On 08/22/2012 05:41 PM, dsimcha wrote: On Wednesday, 22 August 2012 at 20:04:12 UTC, David Nadlinger wrote: On Tuesday, 21 August 2012 at 13:15:49 UTC, dsimcha wrote: Congratulations, Antti-Ville! This project creates a better implementation of precise GC heap scanning than anything that's been created so far for D. The goal is to eventually integrate it into standard D distributions. Great! I've been pretty much out of touch with the GSoC projects this summers, as I had a rather intense exam session at university – are there any progress reports/blog posts with actual numbers in them? David Unfortunately not yet. Antti-ville ran into a lot if difficulty getting things to work and spent the first half of GSoC on an approach that turned out to be the wrong one in hindsight. His project was originally supposed to be improving concurrency support in the GC, but when rtinfo was added to TypeInfo, precise heap scanning seemed like too good an opportunity to pass up. To do this project he had to learn the D template system from scratch. Therefore we didn't have the luxury of the luxury of doing extensive benchmarking and documentation. I plan to work on that with him before he creates a pull request to integrate his new and improved GC upstream. Poolwise bitmap... what an interesting name. I'll look forward to learning about the concepts behind it!
Re: Fragile ABI
On Wednesday, 22 August 2012 at 00:15:12 UTC, David Piepgrass wrote: Lets see how the improved COM (WinRT) turns out to be. Sadly, WinRT is again intended to be Windows-only, so developers like me that hate lock-in will avoid it in preference for .NET (hi Mono!) and yucky old C. Because UNIX systems are still in the stone age in terms of ABI, as they barely changes since the 70's and no one seems to care enough to change things. I like UNIX a lot, but got to know it, after knowing what is possible in more advanced languages, so it always dismays me that specially when dealing with most commercial UNIX it feels like being in the 70's computing age. So that lives only Apple and Microsoft with room for real OS innovation in mainstream OS, and like any vendor they prefer to look for solutions that fit only their OS. Mac OS x is also UNIX, but Apple has been changing it already quite a lot compared with the other vendors, hence my Apple remark. -- Paulo
Re: Fragile ABI
On Friday, 17 August 2012 at 13:49:22 UTC, Jacob Carlborg wrote: Someone has written a piece of code making it easy to use WinRT from D. I don't have the link but it should be possible to find in some of the newsgroups. Are you referring to this: http://lunesu.com/uploads/ModernCOMProgramminginD.pdf ?
Re: Fragile ABI
On 2012-08-22 11:16, xenon325 wrote: On Friday, 17 August 2012 at 13:49:22 UTC, Jacob Carlborg wrote: Someone has written a piece of code making it easy to use WinRT from D. I don't have the link but it should be possible to find in some of the newsgroups. Are you referring to this: http://lunesu.com/uploads/ModernCOMProgramminginD.pdf Yes, exactly. -- /Jacob Carlborg
Vote for the new std.hash (oops, std.digest)
The discussion around new unified API for digest hash functions has subdued, just in time as the review period has ended. The voting for std.digest package starts today and ends on 29 August. Rules are simple: reply in this thread with definite YES or NO on whether this package should go into Phobos. Including descriptive short notes is appreciated (esp. the NO ones). Latest locations of docs and source: Code: (location changed!) https://github.com/jpf91/phobos/tree/newHash/std/digest https://github.com/jpf91/phobos/compare/master...newHash Docs: (location changed!) http://dl.dropbox.com/u/24218791/d/phobos/std_digest_digest.html http://dl.dropbox.com/u/24218791/d/phobos/std_digest_md.html http://dl.dropbox.com/u/24218791/d/phobos/std_digest_sha.html http://dl.dropbox.com/u/24218791/d/phobos/std_digest_crc.html
Re: Fragile ABI
On 2012-08-22 06:32:29 +, Paulo Pinto pj...@progtools.org said: On Wednesday, 22 August 2012 at 00:15:12 UTC, David Piepgrass wrote: Lets see how the improved COM (WinRT) turns out to be. Sadly, WinRT is again intended to be Windows-only, so developers like me that hate lock-in will avoid it in preference for .NET (hi Mono!) and yucky old C. Because UNIX systems are still in the stone age in terms of ABI, as they barely changes since the 70's and no one seems to care enough to change things. I like UNIX a lot, but got to know it, after knowing what is possible in more advanced languages, so it always dismays me that specially when dealing with most commercial UNIX it feels like being in the 70's computing age. So that lives only Apple and Microsoft with room for real OS innovation in mainstream OS, and like any vendor they prefer to look for solutions that fit only their OS. Mac OS x is also UNIX, but Apple has been changing it already quite a lot compared with the other vendors, hence my Apple remark. Actually, the difference is standardization. Microsoft's COM and Apple's Objective-C runtime are built on top of C APIs (and you can access them through C if you want, although it's a little awkward). COM implementations and Objective-C runtime implementations exist for other UNIXes too, as well as other similar things, but no one is pushing them enough for them to become a standard. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: Fragile ABI
On Wednesday, 22 August 2012 at 12:56:12 UTC, Michel Fortin wrote: On 2012-08-22 06:32:29 +, Paulo Pinto pj...@progtools.org said: On Wednesday, 22 August 2012 at 00:15:12 UTC, David Piepgrass wrote: Lets see how the improved COM (WinRT) turns out to be. Sadly, WinRT is again intended to be Windows-only, so developers like me that hate lock-in will avoid it in preference for .NET (hi Mono!) and yucky old C. Because UNIX systems are still in the stone age in terms of ABI, as they barely changes since the 70's and no one seems to care enough to change things. I like UNIX a lot, but got to know it, after knowing what is possible in more advanced languages, so it always dismays me that specially when dealing with most commercial UNIX it feels like being in the 70's computing age. So that lives only Apple and Microsoft with room for real OS innovation in mainstream OS, and like any vendor they prefer to look for solutions that fit only their OS. Mac OS x is also UNIX, but Apple has been changing it already quite a lot compared with the other vendors, hence my Apple remark. Actually, the difference is standardization. Microsoft's COM and Apple's Objective-C runtime are built on top of C APIs (and you can access them through C if you want, although it's a little awkward). COM implementations and Objective-C runtime implementations exist for other UNIXes too, as well as other similar things, but no one is pushing them enough for them to become a standard. Yes, I have to agree. Wasn't Taligent something in that direction? -- Paulo
Re: Null references
On Tue, Aug 21, 2012 at 10:17 PM, Nick Treleaven nos...@example.net wrote: On 21/08/2012 14:30, Simen Kjaeraas wrote: I have an Option struct on my home computer that only allows access to the held value if the error case is simultaneously handled: Option!int a = foo(); int n = a.match!( (int x) = x, (None n) = 0 // or throw, or what have you. ); The same solution is perfectly adaptable to MaybeNull, MaybeNan, and probably a host of others of the same family. With some clever use of opDispatch, one could write an Option struct that lets you call methods and acces members of the wrapped type, and return Option!ReturnType. Apart from the opDispatch bit, I've been slowly working on something similar (Boost license): https://github.com/ntrel/d-maybe/blob/master/maybe.d I'm still working on it, but the basic ideas are there. I think the best bit is apply(), which supports passing multiple Maybe values, calling the delegate only if all Maybes are valid. In fact Maybe.map() is unnecessary due to apply(). Then, both Simen and you could code a generic algebraic datatype generator, with the associated matching functions (and probably mapping / reducing) Here come the whole Haskell / ML menagerie of types :) mixin(ADT( Tree(T): Leaf(T) | Branch(Tree, Tree) )); or something like that... And then encode JSON like this. Or update std.typecons.Algebraic to make it deal with recursive definitions...
Re: Dynamic loading, D all the way (dmd 64bit 2.060/Ubuntu 64bit 12.04/x86_64)
snip If we had dynamic loading, would we be able to do dependency injection in D?
Re: Dynamic loading, D all the way (dmd 64bit 2.060/Ubuntu 64bit 12.04/x86_64)
On Wednesday, 22 August 2012 at 15:51:05 UTC, Philip Daniels wrote: snip If we had dynamic loading, would we be able to do dependency injection in D? Dependency injection does not require dynamic loading per se. It is all about using interfaces instead of classes, and initializing the corresponding instance members. You just need some piece of code that takes the responsibility of locating such interfaces, by registering the classes somehow, or by compile time reflection, which gets called on program initialization. You can do this in D today. -- Paulo
Re: Null references
On Tue, Aug 21, 2012 at 4:55 AM, Regan Heath re...@netmail.co.nz wrote: Plus, I don't buy the argument that having to explicitly type .get will stop anyone from automatically coding statements like: val g: Option[T] = f.doSomething() g.get.doSomethingElse() and suffering the exact same null pointer exception/error despite using Option and boxing into a Not-Null type. R C++ and D have language constructs to allow you to cast away const-ness and immutability, does that mean we have to do away with the concept just because there is a way around it? -- Ziad
Re: Null references
On Wed, 22 Aug 2012 19:37:09 +0200, Ziad Hatahet hata...@gmail.com wrote: C++ and D have language constructs to allow you to cast away const-ness and immutability, does that mean we have to do away with the concept just because there is a way around it? No, but a cast sticks out like a sore thumb. foo.get().bar() does not. -- Simen
[GSOC] New unicode module beta, with Grapheme support!
Well, officially the final bell has rung, marking the end of GSOC. Meaning it's about time to show the project to the community. This time around I sadly have some unresolved issues. Part of these are my fault, others are well known bugs in phobos/compiler. Still there is a lot of cool stuff in there that I'd love to tell about: - all functions isXXX and toUpper/toLower of the old std.uni interface suddenly became faster and/or smarter - icmp function that does proper case insensitive string comparison and matches e.g. german ß (Sulzbacher form) as equal to 'ss' (full casefolding rules) - performance maniacs can use faster/simpler one: sicmp that maps only 1:1 codepoints (simple casefolding rules) - extended grapheme cluster support: decode operation (decodeGrapheme) slightly simpler a-la std.utf.stride to only get the length in codeunits (graphemeStride) - normalization currently only NFD NFKD, have some issues see below (and I still need to triple check the correctness) NFC NFKC are coming soon - decompositon (and composition is coming): either Canonical or Compatibility also yields Grapheme with decomposed codepoint And the last but not least, library users get access to all the power toys used to construct the above algorithms: 1) codepoint sets with full fast set ops 2) highly customizable multi-stage lookup table (aka Trie) with easy helpers to construct optimal multi-level dchar--bool tables 3) a ton of predefined Unicode sets: see general property, block or script Caveats: - the NFC NFKC normalization are in the works, I'll try to get it sometime later this week. - more then that normalization depends on patched Phobos and still often fails due to the bug http://d.puremagic.com/issues/show_bug.cgi?id=4584. Patched Phobos is here: https://github.com/blackwhale/phobos/tree/stable-sort - no 64bit currently. Somehow I managed to broke my _fresh_ 64bit installation of dmd (it fails both on Phobos unit tests anything in my project), thus x64 lacks a bulk of generated tables and is unsupported right now. Any help is appreciated. Grab sources + tests, benchmarks, tools and sample data from: https://github.com/blackwhale/gsoc-bench-2012/zipball/beta And the sketchy DDoc: http://blackwhale.github.com/phobos/std_uni.html The first step to usage is import uni; vs import std.uni; and adding uni.d to your command line. Note: icmp may conflict with its brain dead twin from std.algorithm (or was that std.string?) use the usual tricks to disambiguate as necessary. I'd enjoy some feedback as way back in 2010 I recall a lot of Unicode-aware people longing for grapheme support. A short list of Ali Çehreli, Fawzi Mohamed and Michel Fortin comes to mind maybe others will chime in. P.S. Consider it as ready for comments as opposed to ready for review. P.P.S. Volunteers who'd like to test x64 are welcome to run rdmd gen_uni.d and report back (maybe it's my local setup problem). -- Olshansky Dmitry
Re: [GSOC] New unicode module beta, with Grapheme support!
On Thu, Aug 23, 2012 at 01:31:55AM +0400, Dmitry Olshansky wrote: Well, officially the final bell has rung, marking the end of GSOC. Meaning it's about time to show the project to the community. This time around I sadly have some unresolved issues. Part of these are my fault, others are well known bugs in phobos/compiler. Still there is a lot of cool stuff in there that I'd love to tell about: [...snip list of awesome stuff...] This is awesome!! Finally, the beginnings of better Unicode support. I'm busy with other stuff currently, so I'll have to give more detailed comments later, but from a quick glance over your list, I just have to say +1, well done! T -- Doubt is a self-fulfilling prophecy.
Re: [GSOC] New unicode module beta, with Grapheme support!
Dmitry Olshansky: We still don't know how much long-term success D will have, and not everyone needs advanced Unicode management, but I think this module will help the D success :-) Are the CPU SIMD instructions going to help the performance of some code in this module? - more then that normalization depends on patched Phobos and still often fails due to the bug http://d.puremagic.com/issues/show_bug.cgi?id=4584. I have written a comment there. And I have other things to say, but they are a little OT in this thread, so I'll open another thread soon. Bye and good work, bearophile
Ascii matters
I need to manage Unicode text, but in many cases I have lot of 7-bit or 8-bit ASCII text to process, and this has lead to this discussion, so since some time thanks to Jonathan Davis we have an efficient translate() again: http://d.puremagic.com/issues/show_bug.cgi?id=7515 The s2 array generated by this code is a dchar[] (if array() becomes pure you are probably able to assign type s2 as dstring): string s = test string; // UTF-8, but also 7-bit ASCII dchar[] s2 = map!(x = x)(s).array(); // Uses the Id function To produce a char[] (or string, using assumeUnique), you are free to use a cast: auto s3 = map!(x = cast(char)x)(s).array(); But D casts are unsafe, and one thing I'm learning from Haskell is how important is to give types to your code to prevent bugs. So maybe an AsciiString wrapper (a subtype of string) range can be invented for Phobos. Its consructor verifies the input is a 7-big ASCII and its front method yields chars, so map.array() gives a char[]: astring a1 = test string; // enforced 7-bit ASCII char[] s4 = map!(x = x)(s).array(); This makes some algorithms working on ASCII text cleaner and safer, avoiding the need for casts. Is creating something like this possible and appreciated for Phobos? Bye, bearophile
Re: Null references
Time ago I have suggested a syntax like Foo@ to represent in D the subtype of Foo references that can't be null. That would be nice. Anyhow a lot better as any library solution. But I think it will be resulting in a NotNullable struct in std.typecons...
Re: Ascii matters
On Thursday, August 23, 2012 00:11:18 bearophile wrote: Is creating something like this possible and appreciated for Phobos? It could certainly be done. In fact, doing so would be incredibly trivial. But given that you can use ubyte[] just fine and the fact that using ASCII really shouldn't be encouraged, I don't like the idea of adding such a range to Phobos. I don't know what the general consensus on that would be though. - Jonathan M Davis
Re: Ascii matters
Jonathan M Davis: But given that you can use ubyte[] just fine The data I am processing is not generic octets, like 8 bits digitized by some old A/D converter, they are chars, and I expect to see strings when I print them :-) and the fact that using ASCII really shouldn't be encouraged, For generic text I agree with you, using UTF-8 is safer and better. But there is plenty of scientific/technical text-encoded data that is in ASCII, and for both practical and performance reasons in D I want to process it as a sequence of chars (or a sequence of ubytes, as you say). So for some kinds of data that encouragement is a waste of your time. Bye, bearophile
More on vectorized comparisons
Some time ago I have suggested to add support to vector
comparisons in D, because this is sometimes useful and in the
modern SIMD units there is hardware support for such operations:
double[] a = [1.0, 1.0, -1.0, 1.0, 0.0, -1.0];
bool[] t = a[] 0;
assert(t == [true, true, false, true, false, false]);
Usable instructions like (here shows the intrinsic):
http://msdn.microsoft.com/en-us/library/11dy102s%28v=vs.80%29.aspx
Now on Reddit I have found a small discussion about a slides pack
by Intel:
http://www.reddit.com/r/programming/comments/ym8m6/parallel_programming_for_c_and_c_done_right/
The slides:
https://speakerdeck.com/u/multicoreworld/p/james-reinders-intel-united-states
Link to the PDF:
https://speakerd.s3.amazonaws.com/presentations/5006069136af010002005325/Reinders_KEYNOTE_C_done_right.pdf
At page 69 of those slides there is some code that looks
interesting, I think this is a reduced version of part of it,
that shows another way to use vectorized comparisons:
void main() {
double[] a = [1.0, 1.0, -1.0, 1.0, 0.0, -1.0];
double[] b = [10, 20, 30, 40, 50, 60];
double[] c = [1, 2,3, 4, 5,6];
if (a[] 0)
b[] += c[];
}
I think that code is semantically equivalent to:
void main() {
double[] a = [1.0, 1.0, -1.0, 1.0, 0.0, -1.0];
double[] b = [10, 20, 30, 40, 50, 60];
double[] c = [1, 2,3, 4, 5,6];
foreach (i; 0 .. a.length)
if (a[i] 0)
b[i] += c[i];
}
After that code b is:
[11, 22, 30, 44, 50, 60]
This means the contents of the 'then' branch of the vectorized
comparison is done only on items of b and c where the comparison
has given true.
This looks useful. Is it possible to implement this in D, and do
you like it?
Bye,
bearophile
Re: Ascii matters
On Thursday, August 23, 2012 02:07:52 bearophile wrote:
Jonathan M Davis:
But given that you can use ubyte[] just fine
The data I am processing is not generic octets, like 8 bits
digitized by some old A/D converter, they are chars, and I expect
to see strings when I print them :-)
and the fact that using ASCII really shouldn't be encouraged,
For generic text I agree with you, using UTF-8 is safer and
better.
But there is plenty of scientific/technical text-encoded data
that is in ASCII, and for both practical and performance reasons
in D I want to process it as a sequence of chars (or a sequence
of ubytes, as you say). So for some kinds of data that
encouragement is a waste of your time.
Then just use ubyte[], and if you need char[] for printing out, then cast it.
And if you don't like the casting, you can ever wrap it in a function.
char[] fromASCII(ubyte[] str)
{
return cast(char[])str;
}
Creating an ASCII range type will just encourage its use, when you should only
be operating on ASCII when you really need it. Operating on ASCII is quite
possible as it is and isn't even very hard. So, I really don't see much benefit
in adding such a range, and the fact that arguably would encourage bad
behavior then makes it _undesirable_ rather than just not particularly
beneficial.
- Jonathan M Davis
Re: Ascii matters
On Aug 22, 2012, at 5:07 PM, bearophile bearophileh...@lycos.com wrote: Jonathan M Davis: and the fact that using ASCII really shouldn't be encouraged, For generic text I agree with you, using UTF-8 is safer and better. But there is plenty of scientific/technical text-encoded data that is in ASCII, and for both practical and performance reasons in D I want to process it as a sequence of chars (or a sequence of ubytes, as you say). So for some kinds of data that encouragement is a waste of your time. I'm clearly missing something. ASCII and UTF-8 are compatible. What's stopping you from just processing these as if they were UTF-8 strings?
Re: Ascii matters
On Wednesday, August 22, 2012 19:52:10 Sean Kelly wrote: I'm clearly missing something. ASCII and UTF-8 are compatible. What's stopping you from just processing these as if they were UTF-8 strings? Range-based functions will treat arrays of char or wchar as forward ranges of dchar. Because of the variable length of their code points, they aren't considered to have length, be random access, or have slicing and will not generally work with range-based functions which require any of those operations (though some range-based functions do specialize on strings and use those operations where they can based on proper understanding of unicode). On the other hand, if you have a string that specifically holds ASCII and you know that it only holds ASCII, you know that you can safely use length, random access, and slicing as if each code unit were a full code point. But the range-based functions don't know that your string is guaranteed to be ASCII- only, so they continue to treat it as a range of dchar rather than char. The solution is to either create a wrapper range whose element type is char or to cast the char[] to ubyte[]. And Bearophile wants such a wrapper range to be added to Phobos. - Jonathan M Davis
Re: Ascii matters
Sean Kelly: I'm clearly missing something. ASCII and UTF-8 are compatible. What's stopping you from just processing these as if they were UTF-8 strings? std.algorithm is not closed (http://en.wikipedia.org/wiki/Closure_%28mathematics%29 ) on UTF-8, its operations lead to UTF-32. Bye, bearophile
Re: Ascii matters
Jonathan M Davis: And Bearophile wants such a wrapper range to be added to Phobos. I am just asking if there is interest in it, if people see something wrong in having it in Phobos. Surely I am not demanding it :-) Bye, bearophile
Re: Ascii matters
On Aug 22, 2012, at 8:03 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday, August 22, 2012 19:52:10 Sean Kelly wrote: I'm clearly missing something. ASCII and UTF-8 are compatible. What's stopping you from just processing these as if they were UTF-8 strings? Range-based functions will treat arrays of char or wchar as forward ranges of dchar. Because of the variable length of their code points, they aren't considered to have length, be random access, or have slicing and will not generally work with range-based functions which require any of those operations (though some range-based functions do specialize on strings and use those operations where they can based on proper understanding of unicode). Yeah. I understand why the range-based functions use dchar, but for my own use I generally want to work directly with a char string of UTF-8 so I can slice buffers. Typing these as uchar buffers isn't ideal, but it does work. On the other hand, if you have a string that specifically holds ASCII and you know that it only holds ASCII, you know that you can safely use length, random access, and slicing as if each code unit were a full code point. But the range-based functions don't know that your string is guaranteed to be ASCII- only, so they continue to treat it as a range of dchar rather than char. The solution is to either create a wrapper range whose element type is char or to cast the char[] to ubyte[]. And Bearophile wants such a wrapper range to be added to Phobos. Gotcha. Despite it being something I'd use regularly, I wouldn't want this in Phobos because it seems like it could cause maintenance problems. I'd rather explicitly cast to ubyte as a way to flag that I was doing something potentially unsafe.
Re: [GSOC] New unicode module beta, with Grapheme support!
On 23-Aug-12 02:01, bearophile wrote: Dmitry Olshansky: We still don't know how much long-term success D will have, and not everyone needs advanced Unicode management, but I think this module will help the D success :-) Are the CPU SIMD instructions going to help the performance of some code in this module? Not sure if there is something that does: auto a[] = [1, 3, 5, 8, 10, 20 ...]; //array of [a,b) intervals int b = 9; assert(b in a); //conceptual 'in', checks if a is in one of intervals - more then that normalization depends on patched Phobos and still often fails due to the bug http://d.puremagic.com/issues/show_bug.cgi?id=4584. I have written a comment there. And I have other things to say, but they are a little OT in this thread, so I'll open another thread soon. Bye and good work, Thanks. -- Olshansky Dmitry
struct with @disable(d) default constructor doesn't work with arrays?
I have this struct:
struct S
{
int[] t;
@disable this();
this(int sz)
{
t = new int[sz];
t[] = 1;
}
S opCall(int sz)
{
S s = S(sz);
return s;
}
this(this)
{
t = t.dup;
}
}
Naturally, this doesn't work:
S s; // compiler error
However this does compile.
S[100] s;
S[100] s;
writeln(s[0].t[0]); // range violation error!
I think it's a bug, what do you think?
Re: struct with @disable(d) default constructor doesn't work with arrays?
Minas Mina: I think it's a bug, what do you think? Search for it in Bugzilla. Maybe it's there already. Bye, bearophile
Re: struct with @disable(d) default constructor doesn't work with arrays?
On Wed, 22 Aug 2012 13:09:49 +0200, bearophile bearophileh...@lycos.com wrote: Minas Mina: I think it's a bug, what do you think? Search for it in Bugzilla. Maybe it's there already. Bye, bearophile It is. #7021/#8457 -- Simen
std.widows.registry
If I try to modify a registry value with 'key.setValue()', I get an error 5, which I think is ERROR_ACCESS_DENIED. Even if I right click my .exe and choose 'run as Administrator'. I am on Windows 7 x64, and dmd 2.060. From my research, I think I have to modify my privilege tokens: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387705%28v=vs.85%29.aspx But this example calls methods in advapi that I can't find any bindings for in the D source, namely: OpenProcessToken LookupPrivilegeValueW AdjustTokenPrivileges Any ideas?
Link against MinGW libraries
There's got to be a way to link against libraries generated by MinGW, right? I'm using CMake to create a very simple 1 method library. If I tell D to link against the .lib (simple ar archive), it complains that it's an invalid library. If I tell D to link against the .dll, it complains that there is no .lib. I seem to remember thinking that Microsoft tools create a .dll and a .lib for development libraries, and you link against the .lib but run against the .dll. I don't know how to make MinGW (or cmake for that matter) generate both the .dll and .lib. I seem to remember that other projects I've built with the Visual Studio compiler, I get .lib and .dll files for my shared libraries, and those seem to work. Any help would be appreciated.
Re: std.widows.registry
On Wednesday, 22 August 2012 at 14:52:00 UTC, Kai Meyer wrote: If I try to modify a registry value with 'key.setValue()', I get an error 5, which I think is ERROR_ACCESS_DENIED. Even if I right click my .exe and choose 'run as Administrator'. I am on Windows 7 x64, and dmd 2.060. From my research, I think I have to modify my privilege tokens: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387705%28v=vs.85%29.aspx But this example calls methods in advapi that I can't find any bindings for in the D source, namely: OpenProcessToken LookupPrivilegeValueW AdjustTokenPrivileges Any ideas? Doh, I just found it. REGSAM.KEY_ALL_ACCESS..
Re: Link against MinGW libraries
On Wednesday, 22 August 2012 at 14:56:40 UTC, Kai Meyer wrote: There's got to be a way to link against libraries generated by MinGW, right? I'm using CMake to create a very simple 1 method library. If I tell D to link against the .lib (simple ar archive), it complains that it's an invalid library. If I tell D to link against the .dll, it complains that there is no .lib. I seem to remember thinking that Microsoft tools create a .dll and a .lib for development libraries, and you link against the .lib but run against the .dll. I don't know how to make MinGW (or cmake for that matter) generate both the .dll and .lib. I seem to remember that other projects I've built with the Visual Studio compiler, I get .lib and .dll files for my shared libraries, and those seem to work. Any help would be appreciated. Which D compiler are you using?
function pointer and default argument
hey.
is this valid code?
void func1(int i, double j = 1.0) {
}
void main() {
auto fn = func1;
func1(1); //dmd: ok
fn(1); // dmd: not ok
}
Re: function pointer and default argument
On 08/22/2012 11:51 AM, Ellery Newcomer wrote:
hey.
is this valid code?
void func1(int i, double j = 1.0) {
}
void main() {
auto fn = func1;
func1(1); //dmd: ok
fn(1); // dmd: not ok
}
The type of the function pointer does not include the values of the
default parameters.
The type of fn is a function taking int and a double, returning
nothing. So the compiler must require that information at the call site.
The alternative could work too: The compiler could keep a table from
function pointers to default parameters. But that would be slow.
I am not surprised by dmd's behavior.
Ali
Re: function pointer and default argument
On 08/22/2012 12:03 PM, Ali Çehreli wrote:
On 08/22/2012 11:51 AM, Ellery Newcomer wrote:
hey.
is this valid code?
void func1(int i, double j = 1.0) {
}
void main() {
auto fn = func1;
func1(1); //dmd: ok
fn(1); // dmd: not ok
}
The type of the function pointer does not include the values of the
default parameters.
typeof lies.
pragma(msg, typeof(fn));
void function(int i, double j = 1)
Re: function pointer and default argument
On Wednesday, August 22, 2012 11:51:45 Ellery Newcomer wrote:
hey.
is this valid code?
void func1(int i, double j = 1.0) {
}
void main() {
auto fn = func1;
func1(1); //dmd: ok
fn(1); // dmd: not ok
}
Default arguments are not part of the type. This behavior is very much on
purpose.
http://d.puremagic.com/issues/show_bug.cgi?id=3866
http://d.puremagic.com/issues/show_bug.cgi?id=8402
http://d.puremagic.com/issues/show_bug.cgi?id=8515
- Jonathan M Davis
Re: function pointer and default argument
On 08/22/2012 12:15 PM, Ellery Newcomer wrote:
On 08/22/2012 12:03 PM, Ali Çehreli wrote:
On 08/22/2012 11:51 AM, Ellery Newcomer wrote:
hey.
is this valid code?
void func1(int i, double j = 1.0) {
}
void main() {
auto fn = func1;
func1(1); //dmd: ok
fn(1); // dmd: not ok
}
The type of the function pointer does not include the values of the
default parameters.
typeof lies.
pragma(msg, typeof(fn));
void function(int i, double j = 1)
Opened:
http://d.puremagic.com/issues/show_bug.cgi?id=8579
Ali
Re: SSE2 movddup Not Moving Values
Jonathan Crapuchettes:
Might anyone from this forum have some thoughts for this
problem?
http://stackoverflow.com/questions/12082561/sse2-movddup-not-moving-values
There are some mistakes in that asm code:
import core.stdc.stdio: printf;
import core.cpuid: sse3;
void main() {
assert(sse3());
double d = 1.0 / 2;
auto a = new double[2];
auto aptr = a.ptr;
asm {
mov ESI, aptr;
movddup XMM0, d;
movupd [ESI], XMM0;
}
printf(%f %f\n, a[0], a[1]);
}
Bye,
bearophile
Re: Link against MinGW libraries
On 8/22/2012 11:56 PM, Kai Meyer wrote: There's got to be a way to link against libraries generated by MinGW, right? I'm using CMake to create a very simple 1 method library. If I tell D to link against the .lib (simple ar archive), it complains that it's an invalid library. If I tell D to link against the .dll, it complains that there is no .lib. I seem to remember thinking that Microsoft tools create a .dll and a .lib for development libraries, and you link against the .lib but run against the .dll. I don't know how to make MinGW (or cmake for that matter) generate both the .dll and .lib. I seem to remember that other projects I've built with the Visual Studio compiler, I get .lib and .dll files for my shared libraries, and those seem to work. Any help would be appreciated. The issue is the object file format that the MinGW toolchain uses. It's different from that used by the DMD linker (assuming you are using DMD). What you should do here is download the basic utilities package from the Digital Mars site [1] and use the implib tool on your DLL. This will create a link library in a format the DMD linker understands. Link with it and you should be able to use your DLL. [1] http://www.digitalmars.com/download/freecompiler.html
[Issue 8579] Default parameter appears a part of typeof().stringof of a function variable
http://d.puremagic.com/issues/show_bug.cgi?id=8579 Ali Cehreli acehr...@yahoo.com changed: What|Removed |Added Priority|P2 |P3 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7876] [CTFE] assertion failure on invalid stack reference
http://d.puremagic.com/issues/show_bug.cgi?id=7876 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4584] std.algorithm.sort fails with SwapStrategy.stable
http://d.puremagic.com/issues/show_bug.cgi?id=4584 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2012-08-22 14:41:50 PDT --- (In reply to comment #3) Hit this issue in my project. As part of normalization process codepoints are _stably_ sorted by their canonical combining class. Can dig up a bunch of cases if required but the end result is it rarely works. I have seen this: https://github.com/blackwhale/phobos/commit/23a1cd0b7fac5b4480fee060e240ddda29bed54e So is this problem caused by a DMD bug? If this is true are you able to create a minimal example of the bug? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8579] Default parameter appears a part of typeof().stringof of a function variable
http://d.puremagic.com/issues/show_bug.cgi?id=8579 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #1 from Maxim Fomin ma...@maxim-fomin.ru 2012-08-22 22:22:47 PDT --- Here was a discussion (http://www.digitalmars.com/d/archives/digitalmars/D/What_to_do_about_default_function_arguments_164993.html) but seems the decision about default arguments was not made. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4584] std.algorithm.sort fails with SwapStrategy.stable
http://d.puremagic.com/issues/show_bug.cgi?id=4584 --- Comment #5 from Dmitry Olshansky dmitry.o...@gmail.com 2012-08-22 22:36:30 PDT --- (In reply to comment #4) (In reply to comment #3) Hit this issue in my project. As part of normalization process codepoints are _stably_ sorted by their canonical combining class. Can dig up a bunch of cases if required but the end result is it rarely works. I have seen this: https://github.com/blackwhale/phobos/commit/23a1cd0b7fac5b4480fee060e240ddda29bed54e So is this problem caused by a DMD bug? If this is true are you able to create a minimal example of the bug? No, it's just that $ works only with arrays (still). And in order for sort(zip(...)) to work I need this minor fix. The bug with stable sort was there for 2 years now and I don't realy know the cause. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
