Re: Coming Soon: Stable D Releases!
On Mon, 16 Jul 2012 13:05:29 -0700, Brad Anderson e...@gnuk.net wrote: On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: [snip] I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is basically no additional work, whereas Adam doing essentially the same is an unenviable amount of labor. He wouldn't be cherry-picking anything. All he'd have to do is a checkout (one command) before switching between working on features (and by features I mean breaking or major changes) or bugs. Adam, on the other hand, would be running git cherry-pick over and over dodging changes he determines are too risky to include in stable. It also seems like there is a lot more room for mistakes to be made doing it this way. There certainly is more room for mistakes, which is why I think that a team-based approach is better. I've also finished putting together some scripts to automate the various processes. I think that the merge script can especially take a lot of the work and time out of the equation. With a single call we can merge as many commits as we feel comfortable with, build them, run unittests and push the changes to the server. At this point i'll probably spend more time deciding which commits are safe to pick than I will actually merging them. At least until I hit a decent merge conflict. But hey, everything helps! :-) Scripts are available here: https://github.com/dlang-stable/utilities Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus. Perhaps. More eyes are better. It just seems like way more work than is necessary to accomplish the goal of isolating breaking changes so that stable releases can go out easier. The end result is all I'm interested in personally since I'm not the one doing the work here. I'm not too concerned with whether you use my idea or not. I just thought you guys might like to hear an alternative that is much easier for you while remaining easy for Walter. Regards, Brad Anderson -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 22 de July a las 16:05 me escribiste: I can't really say, but it sounds like what you are asking for is D2/D3, thats not really the scope of the dlang-stable project, we Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody said before in this thread talking about PHP, minor version changes in the languages should only introduce backward compatible new features. D3 should be allowed to break backward compatibility while D 2.1 should not. The same is done in Python. In Python is even allowed to break backward compatibility in very small and are cases, like introducing a keyword. In those cases the changes are introduced in steps, let's say in Python 2.5 with is not a keyword and they want to convert it to a keyword. Then in Python 2.6 you have an option to enable that behaviour (disabled by default) and in Python 2.7 the new feature will be enabled by default. Python 2.5.1 can only introduce bugfixes. This is something I think D needs since ages ago[1], and I thought it was finally here, but from what you say it doesn't like that way :S [1] http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- There is no pain you are receding A distant ship, smoke on the horizon. You are only coming through in waves. Your lips move but I can't hear what you're saying.
Re: Coming Soon: Stable D Releases!
On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella l...@llucax.com.ar wrote: Adam Wilson, el 22 de July a las 16:05 me escribiste: I can't really say, but it sounds like what you are asking for is D2/D3, thats not really the scope of the dlang-stable project, we Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody said before in this thread talking about PHP, minor version changes in the languages should only introduce backward compatible new features. D3 should be allowed to break backward compatibility while D 2.1 should not. The same is done in Python. In Python is even allowed to break backward compatibility in very small and are cases, like introducing a keyword. In those cases the changes are introduced in steps, let's say in Python 2.5 with is not a keyword and they want to convert it to a keyword. Then in Python 2.6 you have an option to enable that behaviour (disabled by default) and in Python 2.7 the new feature will be enabled by default. Python 2.5.1 can only introduce bugfixes. Minor release ARE what we are hoping for, but you'll have to convince Walter and company to move to that scheme, it's out of my control. For the moment, we will be using a scheme that looks like 2.60.1. Which may be what you are talking about. When it's time to roll in the new features and breaking fixes the stable release will be bumped to 2.61.1. Is this what you are asking for? This is something I think D needs since ages ago[1], and I thought it was finally here, but from what you say it doesn't like that way :S [1] http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- There is no pain you are receding A distant ship, smoke on the horizon. You are only coming through in waves. Your lips move but I can't hear what you're saying. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Optional name mangling
On 2012-07-22 15:12, Stuart wrote: I don't know why implib is ignoring the /s switch, but it is. My .lib file doesn't have underscores, and there doesn't seem to be much I can do about it. Do I need a different version of implib or something? Shouldn't the /s switch add underscores to everything? I used it a couple of weeks ago and it worked. -- /Jacob Carlborg
Re: Time for std.reflection
On Sun, Jul 22, 2012 at 4:28 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
std.reflection could become the lynchpin for dynamic library use; once the
library is loaded (with dlopen or such), the client needs to call
getModuleInfo() (a C function that can be found with dlsym()) and then get
access to pointers to functions necessary for doing all other work. (Note
that my examples don't yet include pointers to executable code yet.)
I wouldn't know. I have no experience with dlsym().
2) Why classes, as opposed to structs? Would inheritance/hierarchies
play a role there? Or reference semantics?
Note that between structs, classes, templates and modules there is a
lot of redundancy. A possibility could be to have an AggregateInfo
base class.
Initially I used struct, but then I figured reference semantics are more
natural for storing cross-entity information, as you indeed took advantage
of in your TemplateInfo.
I realized a few minutes after posting I answered my own question:
because this is a self-referencing structure (a tree, a graph), which
are easier to code with classes than structs.
4) How would that allows queries like Here is class C, give me all
its available subclasses.? Hmm, wait, I get it: extract classes from
the module, and recursively from imported modules. From these classes,
extract the parent classes and so on, until the search ranged over the
whole inheritance tree. I guess inheritance info could be standard
enough for std.reflection to provide such a search.
Something like that. Note that such a query is not particularly OO-ish,
because getting a class' cone (totality of subclasses) works against the
modularity that inheritance is meant for. I don't think we should make
getting class cones particularly easy.
Right. Since people here asked this question, I thought that was a
common request in OO. I'm more a structs and mixins guy, myself.
5) The compiler can emit JSON output giving a partial view of the same
information. As a long-term goal, I suggest these infos should be
compatible somehow. The JSON output should be enriched, and we should
ascertain that using std.json to read this kind of
automatically-generated information should give std.reflection infos
back.
Yes, that's a great connection that Walter and I discussed a bit.
Good to know.
6) Is really all the necessary info available through std.traits and
__traits? Imported modules and their subtilities (renamed functions,
etc) seem out of reach, no?
We'll need indeed to enhance __traits with what's needed. Much of the point
of std.reflection is to determine exactly what's there and what's needed.
And that starts with the data structures design (the algorithmic aspects are
minor).
+1 for enhancing __traits locally.
- having __traits(allMembers, xxx) work on simple module names, and
not only on qualified package.module names
- having a way to get imports and a way to know whether they are
static / renaming import
As for the data structures, other people's designs allured to in this
thread seem similar to your proposal.
I have two other questions:
About functions: should they be subject to reflection also, or not?
They have no fields, inner functions are totally interned, etc. All a
user need is the 'interface', right? (name, and everything that's in
the type: return type, parameters, purity, etc)
About imports, what about inner imports, now that they are authorized
in almost any scope? My gut feeling right now is that a user does not
care if class C internally import std.algorithm in one of its methods,
but I could be wrong.
7) I know your examples are not complete, but don't forget aliases and
symbols, and module-level values. Since these can be of any type, I'm
not sure how they are managed in your scheme. I mean, you cannot have
IntInfo[], DoubleInfo[], ...
I sort of eschewed part of that by using strings for types.
I see. They can be managed like fields in an aggregate (struct /
classes), as there are many similarities between D modules and classes
/ structs.
class ModuleInfo {
@property:
...
FieldInfo[] data; // also used in StructInfo and ClassInfo
}
class FieldInfo {
@property:
string name();
bool isStatic();
Protection protection();
string type();
}
As long as this info is available at CT, FieldInfo.type can be
mixed-in and used in code.
what I'm not sure I get in your design is why some informations are
encoded in their own structure, like Protection above (the code is
copy-pasted from yours, I'd guess Protection is an enumeration), and
then some others are encoded as strings (types). Is that because the
values Protection can take are known in advance (and finite)?
I wondered whether a design like this could be interesting?:
abstract class FieldInfo {}
class Field(T) : FieldInfo {
@property:
string name();
bool isStatic();
Protection protection();
alias T Type;
}
But that doesn't cut it, AFAICT:
Re: Time for std.reflection
On Sun, Jul 22, 2012 at 5:10 PM, Max Samukha maxsamu...@gmail.com wrote:
The language does not allow you to use CTFE parameter values as arguments to
__traits/templates. Therefore, to be able to build meta-objects at
compile-time, you would have to:
static info = getModuleInfo!std.algorithm;
Maybe I don't get your comment, but AFAICT, the language does allow
you to use CTFE parameters values as arguments to templates:
template Twice(double d)
{
enum Twice = d * 2;
}
double foo(double d)
{
return d+1.0;
}
void main()
{
enum t = Twice!(foo(1.0));
pragma(msg, t);
}
Re: Time for std.reflection
On 2012-07-21 23:44, Andrei Alexandrescu wrote: Walter and I discussed the idea below a long time (years) ago. Most likely it's also been discussed in this newsgroup a couple of times. Given the state of the compiler back then, back then it seemed like a super cool idea that's entirely realizable, it would just take time for the compiler to become as capable as needed. Nowadays we're in shape to tackle it. Here it is. Back when runtime reflection was being discussed, my response was let's focus on compile-time reflection, and then we can do run-time reflection on demand as a library. Though this might sound sensible, I initially didn't have a design. Now here's what we can do. I've been waiting for this :) -- /Jacob Carlborg
Re: Time for std.reflection
On 2012-07-22 14:04, deadalnix wrote: I'd expect from std.reflection that it is able to reflect recursively from the marked starting point. I really hope so. -- /Jacob Carlborg
Re: Time for std.reflection
On 2012-07-22 06:48, Andrei Alexandrescu wrote: P.S. What this thing wit quoting a long message to make a 1-line point? Is that a thing? It's the new hip thing :) -- /Jacob Carlborg
Re: Time for std.reflection
On 2012-07-22 02:16, Kapps wrote: I agree with most things proposed, however I am not a fan of the idea of mixing in runtime reflection info. Many times, you want reflection info from a type that is not your own, and thus I believe reflection should be generated by specifying a type. More importantly, a method should exist for recursively generating reflection info. I agree. -- /Jacob Carlborg
Re: Time for std.reflection
On Sun, Jul 22, 2012 at 6:15 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 7/22/12, Philippe Sigaud philippe.sig...@gmail.com wrote: 2) Why classes, as opposed to structs? I think either way you'd need reference semantics. Yeah, I agree, reference semantics look better. And since there is a lot of duplication (struct info is a subtype of class info, itself looking very uch like a module info, I guess a mini-hierarchy is possible). So I'm convinced classes look like a good fit. You could use structs as well, and actually I use structs in my codegenerator (with a similar layout to what Andrei posted). Each struct (e.g. Class/Function) stores Symbols, which are structs with an ID and a Type. I can look up each symbol in a SymTable which actually holds the structures with data. So a Symbol is like a fake pointer, and the SymTable would be the memory. I originally planned to use classes but some serialization frameworks didn't work with those so I settled using structs and a bit of template mixin magic instead. Could you describe your design in this thread, and possibly link to some code? All of this std.reflection talk is quite exciting actually. It is! If you had AST information about your entire D library you could do some really cool things. You could make a better documentation generator than ddoc, or export the AST into a file for a code-completion plugin, or create a wrapper C library which enables other languages to use your D library. You could do macros. 'nuff said.
Re: Just where has this language gone wrong?
On Sunday, 22 July 2012 at 21:10:08 UTC, Andrei Alexandrescu
wrote:
On 7/22/12 12:32 PM, David Nadlinger wrote:
On Sunday, 22 July 2012 at 03:06:28 UTC, Jens Mueller wrote:
Where is argmin defined? I couldn't find it.
On the slide before that… ;)
I think argmin is intuitive, popular, and useful enough to
warrant a presence in std.algorithm. Would anyone want to do
the honors?
Thanks,
Andrei
Are you asking for the _actual_ argmin as defined in the paper?
Because I think it would be much better if we provided an
overload for the existing minPos/minRange to accept a unary pred:
Range minPos(alias pred, Range)(Range range)
if (is(typeof(unaryFun!pred(range.front
{
...
}
Tuple!(ElementType!(Range), size_t)
minCount(alias pred, Range)(Range range)
if (is(typeof(unaryFun!pred(range.front
{
...
}
Where pred if the unary weight function. This code would then
work as such:
auto m = s.minPos!((x) = x.length).front;
auto m = s.minCount!((x) = x.length)[1];
Both versions require an extra .front/[1], but that's because
that's just how the algorithms work.
I actually _just_ rewrote these two methods (they are in my pull
requests). I'm on it if you you like the idea of being able to
call these functions with a unary predicated (I do): It sure
beats writing (a, b) = pred(a) pred(b) when you could just
write a = pred(a)
Re: Time for std.reflection
On 2012-07-22 16:28, Andrei Alexandrescu wrote: Something like that. Note that such a query is not particularly OO-ish, because getting a class' cone (totality of subclasses) works against the modularity that inheritance is meant for. I don't think we should make getting class cones particularly easy. I see no reason to make it difficult on purpose. -- /Jacob Carlborg
Re: Time for std.reflection
On 23-Jul-12 10:30, Philippe Sigaud wrote: Well you're the resident crazy-stuff-during-compilation guy. Ah! I wish. I had this wonderful idea of having code be parsed at CT, semantically analyzed, transformed into some machine code at CT and... , oh wait. I kind of did it... regex pattern ---parse--- bytecode ---generate D code--- profit. BTW you can avoid machine code, just use D code as glorified backend :) (and get optimizations for free, yay!) -- Dmitry Olshansky
Re: Optional name mangling
On 7/22/2012 6:12 AM, Stuart wrote: Okay, but if you had a keyword - say, extern(rawC) - that did no mangling whatsoever, then I could run implib without manually editing every single damn line in every Microsoft .def file by hand!!! Surely that's a good idea? I agree, it's a pain, and a pointless one at that. I don't know why implib is ignoring the /s switch, but it is. My .lib file doesn't have underscores, and there doesn't seem to be much I can do about it. Do I need a different version of implib or something? Shouldn't the /s switch add underscores to everything? There's no magical way for implib to figure out what the nn in @nn must be.
Re: Time for std.reflection
On Mon, Jul 23, 2012 at 8:41 AM, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 23-Jul-12 10:30, Philippe Sigaud wrote: Well you're the resident crazy-stuff-during-compilation guy. Ah! I wish. I had this wonderful idea of having code be parsed at CT, semantically analyzed, transformed into some machine code at CT and... , oh wait. I kind of did it... regex pattern ---parse--- bytecode ---generate D code--- profit. BTW you can avoid machine code, just use D code as glorified backend :) (and get optimizations for free, yay!) Hey, that was a joke, about implementing a D compiler in D, to be executed at CT by the real D compiler to basically do its job a second time, only worse :) But yes, your regex work is a great example. I should have a look at the code once more.
Re: Time for std.reflection
On 23-Jul-12 10:47, Philippe Sigaud wrote: On Mon, Jul 23, 2012 at 8:41 AM, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 23-Jul-12 10:30, Philippe Sigaud wrote: Well you're the resident crazy-stuff-during-compilation guy. Ah! I wish. I had this wonderful idea of having code be parsed at CT, semantically analyzed, transformed into some machine code at CT and... , oh wait. I kind of did it... regex pattern ---parse--- bytecode ---generate D code--- profit. BTW you can avoid machine code, just use D code as glorified backend :) (and get optimizations for free, yay!) Hey, that was a joke, about implementing a D compiler in D, to be executed at CT by the real D compiler to basically do its job a second time, only worse :) Yeah, now I think I got it. Could be a nice benchmark for CTFE though :) But yes, your regex work is a great example. I should have a look at the code once more. I'd advice to wait a bit ... it's not really in a good shape (to read it) as there have been tons of improvements in CTFE since the last time I've touched it. I'll have to revisit it and remove some roundabout workarounds. -- Dmitry Olshansky
Re: Time for std.reflection
On 7/23/12 2:39 AM, Jacob Carlborg wrote: On 2012-07-22 16:28, Andrei Alexandrescu wrote: Something like that. Note that such a query is not particularly OO-ish, because getting a class' cone (totality of subclasses) works against the modularity that inheritance is meant for. I don't think we should make getting class cones particularly easy. I see no reason to make it difficult on purpose. The reason is that often the cone would be incomplete and therefore confusing. It would also foster non-modular approaches to doing things. Andrei
Re: OSCON 2012 notes
Nick Sabalausky wrote in message news:20120723010439.6efc@unknown... I wouldn't know. I haven't actually dealt with the android SDK directly, only Marm. When I saw google saying you use either Java or straight natively-compiled C++, I guess I assumed that meant an actual C++ API. No, actually you are still dealing with JNI. Google's position on native code, is that you should use it just for code hotspots, gamming or to port legacy code. [quote]In general, you should only use the NDK if it is essential to your app— never because you simply prefer to program in C/C++.[/quote] http://developer.android.com/tools/sdk/ndk/index.html The native activity is actually a Java Activity with a specific set of methods defined as native methods. http://developer.android.com/reference/android/app/NativeActivity.html You are only allowed to access these libraries: - libc (C library) headers - libm (math library) headers - JNI interface headers - libz (Zlib compression) headers - liblog (Android logging) header - OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers - libjnigraphics (Pixel buffer access) header (for Android 2.2 and above). - A Minimal set of headers for C++ support - OpenSL ES native audio libraries - Android native application APIS The Android native applications APIs are C wrappers around JNI calls, meaning you get a performance hit when calling them due to marshling. This is described in the STABLE-APIS.html document delivered as part of the NDK. [quote]Starting from API level 9, it is possible to entirely write an Android application with native code (i.e. without any Java). That does not mean that your code does not run inside a VM though, and most of the features of the platform will still need to be accessed through JNI.[/quote] Java is the main language to develop standard applications on Android, everything else are just workarounds, even if we don't like it. Another example are the new low level Codec APIs in Jelly Bean, which are only exposed directly via JNI to Java. http://developer.android.com/reference/android/media/MediaCodec.html -- Paulo
Re: Preview LLVM Deimos bindings
Am 22.07.2012 12:10, schrieb Jens Mueller: Sönke Ludwig wrote: Am 20.07.2012 07:35, schrieb Jens Mueller: Hi, I've written some Deimos interface for LLVM. https://github.com/jkm/deimos-llvm/commits/master I'd like to get some feedback on those. Firstly to finish these and secondly to finish some guidelines that I'd like to propose to be published on dlang.org. Jens Are the bindings for 3.0 or 3.1? I'm asking because at least some enum members have changed (don't exactly remember which). It's 3.1. Jens Ok great, then I can throw away my bindings :) (unfortunately I couldn't publish them because of my former employee...). Btw. regarding Barnard's comment about LLVM-C, I partially agree. Several additions/modifications were necessary in my case to be able to make the compiler fully work. I wonder if it's feasable to compile LLVM using DMC and then use extern(C++) to make an object oriented interface at some point, possibly using SWIG or something. But well.. apart from some missing features, I think the C interface is actually OK to work with, once you get over the missing documentation, so maybe it's really not worth the time.
Re: OSCON 2012 notes
On 2012-07-21 21:59, Alex Rønne Petersen wrote: On 21-07-2012 21:51, Nick Sabalausky wrote: Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count Son-of-Flash, ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. ... and C# ;) ... and Ruby :) -- /Jacob Carlborg
Re: Time for std.reflection
On 2012-07-23 08:35, Philippe Sigaud wrote: On Sun, Jul 22, 2012 at 6:15 PM, Andrej Mitrovic If you had AST information about your entire D library you could do some really cool things. You could make a better documentation generator than ddoc, or export the AST into a file for a code-completion plugin, or create a wrapper C library which enables other languages to use your D library. You could do macros. 'nuff said. If I recall correctly, Scala uses its reflection API as a part off its macros. -- /Jacob Carlborg
Re: OSCON 2012 notes
On 2012-07-23 08:59, Paulo Pinto wrote: No, actually you are still dealing with JNI. Google's position on native code, is that you should use it just for code hotspots, gamming or to port legacy code. The Android native applications APIs are C wrappers around JNI calls, meaning you get a performance hit when calling them due to marshling. This is described in the STABLE-APIS.html document delivered as part of the NDK. [quote]Starting from API level 9, it is possible to entirely write an Android application with native code (i.e. without any Java). That does not mean that your code does not run inside a VM though, and most of the features of the platform will still need to be accessed through JNI.[/quote] That is just so wrong. -- /Jacob Carlborg
Re: Preview LLVM Deimos bindings
On 2012-07-23 08:56, Sönke Ludwig wrote: Ok great, then I can throw away my bindings :) (unfortunately I couldn't publish them because of my former employee...). Btw. regarding Barnard's comment about LLVM-C, I partially agree. Several additions/modifications were necessary in my case to be able to make the compiler fully work. I wonder if it's feasable to compile LLVM using DMC and then use extern(C++) to make an object oriented interface at some point, possibly using SWIG or something. But well.. apart from some missing features, I think the C interface is actually OK to work with, once you get over the missing documentation, so maybe it's really not worth the time. https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: Time for std.reflection
On Mon, 23 Jul 2012 08:32:37 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
Maybe I don't get your comment, but AFAICT, the language does allow
you to use CTFE parameters values as arguments to templates:
template Twice(double d)
{
enum Twice = d * 2;
}
double foo(double d)
{
return d+1.0;
}
void main()
{
enum t = Twice!(foo(1.0));
pragma(msg, t);
}
Wrong way around. Try this:
template Twice(double d)
{
enum Twice = d * 2;
}
double foo(double d)
{
return Twice!d;
}
void main()
{
enum t = foo(1.0);
pragma(msg, t);
}
--
Simen
Re: Computed gotos on Reddit
On 23-07-2012 05:05, deadalnix wrote: On 23/07/2012 01:35, bearophile wrote: A discussion appeared few days ago on Reddit, about computed gotos: http://www.reddit.com/r/programming/comments/wld04/eli_benderskys_website_computed_goto_for/ http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables/ The presented example is insanely unsafe. By giving invalid input, you can basically branch randomly. The check added by the switch is what is required to make it safe, so it isn't faster at the end. The case in the article isn't very strong. You should always verify your bytecode before executing it anyway. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSCON 2012 notes
On Mon, 23 Jul 2012 08:59:32 +0200 Paulo Pinto pj...@progtools.org wrote: Nick Sabalausky wrote in message news:20120723010439.6efc@unknown... I wouldn't know. I haven't actually dealt with the android SDK directly, only Marm. When I saw google saying you use either Java or straight natively-compiled C++, I guess I assumed that meant an actual C++ API. No, actually you are still dealing with JNI. Google's position on native code, is that you should use it just for code hotspots, gamming or to port legacy code. [quote]In general, you should only use the NDK if it is essential to your app— never because you simply prefer to program in C/C++.[/quote] http://developer.android.com/tools/sdk/ndk/index.html The native activity is actually a Java Activity with a specific set of methods defined as native methods. http://developer.android.com/reference/android/app/NativeActivity.html You are only allowed to access these libraries: - libc (C library) headers - libm (math library) headers - JNI interface headers - libz (Zlib compression) headers - liblog (Android logging) header - OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers - libjnigraphics (Pixel buffer access) header (for Android 2.2 and above). - A Minimal set of headers for C++ support - OpenSL ES native audio libraries - Android native application APIS The Android native applications APIs are C wrappers around JNI calls, meaning you get a performance hit when calling them due to marshling. This is described in the STABLE-APIS.html document delivered as part of the NDK. [quote]Starting from API level 9, it is possible to entirely write an Android application with native code (i.e. without any Java). That does not mean that your code does not run inside a VM though, and most of the features of the platform will still need to be accessed through JNI.[/quote] Java is the main language to develop standard applications on Android, everything else are just workarounds, even if we don't like it. Another example are the new low level Codec APIs in Jelly Bean, which are only exposed directly via JNI to Java. http://developer.android.com/reference/android/media/MediaCodec.html Gah! What the fuck is this, 1998?!? (Why can't we finally just let Java die as the wretched idea it always was?) I've always seen Android as a slightly-less-shitty clone of iOS. But every time I turn around, I discover another way Google seems hell-bent on proving me wrong. They ape most of Apple's bad ideas and then toss in some of their own. How the hell is it even *possible* for another company to compete this well with Apple on retarded design decisions? I suppose with the death of Jobs it was inevitable for another company to successfully surpass Apple's horridness, but I always figured it would be from Apple getting slightly less crappy or fading back into their 90's obscurity where they belong - not from others sinking down to sub-Jobsian idiocy. I'd never even considered that a possibility. Very depressing. I miss Woz's computers. Fuck, I even miss the days when Microsoft ruled the world with an iron fist. At least back then platforms were open and software/hardware designs were relatively sane from a user's standpoint (even if the code behind them wasn't).
Re: Computed gotos on Reddit
On Sunday, 22 July 2012 at 23:35:34 UTC, bearophile wrote: A discussion appeared few days ago on Reddit, about computed gotos: For another use case: dotat.at/tmp/gll.pdf
Re: Time for std.reflection
On Mon, Jul 23, 2012 at 9:46 AM, Simen Kjaeraas simen.kja...@gmail.com wrote:
Wrong way around. Try this:
template Twice(double d)
{
enum Twice = d * 2;
}
double foo(double d)
{
return Twice!d;
}
void main()
{
enum t = foo(1.0);
pragma(msg, t);
}
Ah, that, OK. And __ctfe does not help.
Would it really limit the proposed scheme for std.reflection?
Re: #d_lang ---- #dlang on Twitter?
Brad Anderson e...@gnuk.net wrote: On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei #dlang is what people have been using on G+. You'll have to Oops, I didn't get the memo. Next time it will be right.
of Conditional Implementation vs Assertive Input Validation
I've been putting my nose in std.algorithm recently,
specifically, requirements of algorithms.
I must say I'm a big fan of conditional implementations. Given
the genericity of templates (!), it can be very hard to overload
them correct without conditional implementation. It is a really
useful language feature
That said, more often than not, they are also used to validate
input. While this is a good thing, when a developer DOES try to
call an algorithm with invalid input, he is greeted with the
cryptic:
Error: template foo does not match any function template
declaration
Followed by the (potentially long) list of candidates.
More often than not, the conditional implementations are actually
quite complicated, and contain up to 5 or 6 different conditions.
The worse part is that the developer has no idea _which_
condition he has violated.
This is a shame, since most of the time, the conditions are not
necessary for disambiguation, and a static assert would work just
as well, and be more verbose.
Simple example:
minPos doesn't shouldn't operate on infinite ranges. compare:
Range minPos(Range)(Range R1) if (is(inputRange!Range)
!isInfinite!Range) {...}
vs
Range minPos(Range)(Range R1) if (is(inputRange!Range)
{
static assert(!isInfinite!Range, minPos cannot operate on
infinite ranges.)
...
}
Now, if a developer ever accidentally calls minPos with an
infinite range, he gets slapped in the face with a very explicit
compilation warning. This (I think) is great, because the
isInfinite test is really just an implementation detail.
inputRange is really the input condition of the range, and should
stay conditional.
How do you feel about assertive input validation vs
conditional implementation?
Is this something you'd like to see more of in algorithm?
Re: of Conditional Implementation vs Assertive Input Validation
On Monday, 23 July 2012 at 11:10:39 UTC, monarch_dodra wrote: Is this something you'd like to see more of in algorithm? Yes! Improving error messages is very important. Maybe we find a better solution on compiler level but in the meantime [not only] std.algorithm will benefit from your solution.
Re: OSCON 2012 notes
On 2012-07-23 05:04:39 +, Nick Sabalausky seewebsitetocontac...@semitwist.com said: Personally I like abstraction layers for GUI: it means you don't have to deal with twenty different system-specific (and idiosyncratic) APIs. For example, I hope I never have to touch Win32 directly again. Win32 is a special case. It's old and low-level, no one wants to touch it. Even those who build directly on it abstract it with a layer of their own. Abstraction layers for GUI are not inherently bad, but they also tend to blur platform specificities. This often results in apps that feel a little alien on every platform. So whether you should use them or not depends on your priorities. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: of Conditional Implementation vs Assertive Input Validation
It certainly makes sense. Maybe the long term solution would be
a way to embed those assertions in the conditions, but in the
meantime the proposal would alleviate the error message issue. I
know I've often enough stared long and hard at a volume of
template instantiation errors waiting for the real mistake to
jump out at me.
--
And for the curious, what I mean by embedding assertions in the
conditions is quite literally what it sounds like:
Range minPos ( Range ) ( Range R1 )
if( is( inputRange!Range ) )
assert( !isInfinite!Range, minPos cannot operate on infinite
ranges. )
{
...
}
In which case the compiler would merge the condition expressions
of the assertions into the if-condition, and remember the message
strings associated with them.
Re: of Conditional Implementation vs Assertive Input Validation
On 2012-07-23 13:10, monarch_dodra wrote: I've been putting my nose in std.algorithm recently, specifically, requirements of algorithms. I must say I'm a big fan of conditional implementations. Given the genericity of templates (!), it can be very hard to overload them correct without conditional implementation. It is a really useful language feature That said, more often than not, they are also used to validate input. While this is a good thing, when a developer DOES try to call an algorithm with invalid input, he is greeted with the cryptic: Error: template foo does not match any function template declaration Followed by the (potentially long) list of candidates. More often than not, the conditional implementations are actually quite complicated, and contain up to 5 or 6 different conditions. I think this is really a problem with std.algorithm. -- /Jacob Carlborg
Re: Preview LLVM Deimos bindings
Am 23.07.2012 09:16, schrieb Jacob Carlborg: On 2012-07-23 08:56, Sönke Ludwig wrote: Ok great, then I can throw away my bindings :) (unfortunately I couldn't publish them because of my former employee...). Btw. regarding Barnard's comment about LLVM-C, I partially agree. Several additions/modifications were necessary in my case to be able to make the compiler fully work. I wonder if it's feasable to compile LLVM using DMC and then use extern(C++) to make an object oriented interface at some point, possibly using SWIG or something. But well.. apart from some missing features, I think the C interface is actually OK to work with, once you get over the missing documentation, so maybe it's really not worth the time. https://github.com/jacob-carlborg/dstep I thought it doesn't yet support C++? But anyways, next time I have to make bindings for a C library I'll definitely try dstep.
Re: OSCON 2012 notes
On 2012-07-23 13:21, Michel Fortin wrote: Abstraction layers for GUI are not inherently bad, but they also tend to blur platform specificities. This often results in apps that feel a little alien on every platform. So whether you should use them or not depends on your priorities. I think a system where the common widgets, i.e. windows, buttons and similar, are abstracted but still lets you easily access the native API would be a good thing. This mean you would still need to be able to access the Objective-C and WinRT object model to be really useful. -- /Jacob Carlborg
Re: Preview LLVM Deimos bindings
On 2012-07-23 13:45, Sönke Ludwig wrote: I thought it doesn't yet support C++? But anyways, next time I have to make bindings for a C library I'll definitely try dstep. No, it doesn't support C++. I was thinking about generating bindings for the C API. -- /Jacob Carlborg
Re: D versionning
On 16/07/12 23:33, Jonathan M Davis wrote: We're talking about doing something similar to having 2.x.y, with the main branch incrementing x and the stable branch incrementing y. Going to v3 would mean incrementing the 2. We have _no_ intention of doing that for years to come. Just to note that, in the sense of making major changes to the language design, you're obviously right -- but I don't see the problem with bumping the major version number just to indicate that some key milestone has been passed (e.g. implementing in entirely the features described in TDPL). That might even be a _good_ way of indicating to the wider development world that you have a really well-defined stable release.
Re: Preview LLVM Deimos bindings
On Monday, 23 July 2012 at 06:56:26 UTC, Sönke Ludwig wrote: I wonder if it's feasable to compile LLVM using DMC and then use extern(C++) to make an object oriented interface at some point, possibly using SWIG or something. The fact that the LLVM C++ API uses templates quite heavily might turn out to be a problem in that regard. I didn't have a look at how feasible it would be to just »pre-instantiate« all the needed combinations, though. David
Re: Just where has this language gone wrong?
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote: C++ is living in the 70's. Precisely what I have been thinking. It's a loose wrapper around assembly, nothing more. Certainly not the high-level language it's touted as.
Re: Optional name mangling
On Monday, 23 July 2012 at 06:28:56 UTC, Jacob Carlborg wrote: On 2012-07-22 15:12, Stuart wrote: I don't know why implib is ignoring the /s switch, but it is. I used it a couple of weeks ago and it worked. Oh, well, I guess that makes it alright, huh? I guess I must just be an idiot, or hallucinating, yeah? Alternatively, you could take my word for it when I say it ain't working, and offer some kind of constructive advice.
Re: Optional name mangling
On Monday, 23 July 2012 at 06:44:22 UTC, Walter Bright wrote: On 7/22/2012 6:12 AM, Stuart wrote: Okay, but if you had a keyword - say, extern(rawC) - that did no mangling whatsoever, then I could run implib without manually editing every single damn line in every Microsoft .def file by hand!!! Surely that's a good idea? I agree, it's a pain, and a pointless one at that. I don't know why implib is ignoring the /s switch, but it is. My .lib file doesn't have underscores, and there doesn't seem to be much I can do about it. Do I need a different version of implib or something? Shouldn't the /s switch add underscores to everything? There's no magical way for implib to figure out what the nn in @nn must be. Granted, but IMPLIB IS NOT PREFIXING THE NAMES WITH AN UNDERSCORE, even when used with the /s switch. Hello? Houston? Am I getting through? In any case, adding support for importing unmangled function names in D would help in these cases; and also allow us to import unmangled functions that were exported from C using the extern C instruction in C++. Correct me if I'm wrong, but isn't it only C++ that does mangling? As I recall, straight C doesn't support overloading and doesn't mangle names. Therefore, I reckon your extern (C) instruction ought instead to be written extern (C++), and a new extern (C) should be introduced that does no name mangling. Alternatively, I may be wrong, but even so, a non-mangling keyword would be helpful. And surely it wouldn't be difficult to implement?
Re: Let's stop parser Hell
On Thu, Jul 5, 2012 at 10:00 PM, Tobias Pankrath tob...@pankrath.net wrote: If you are interested in parsing, than I wouldn't recommend the dragon book, but this one It really is an awesome book. This little post to say a big 'Thanks' to Tobias. I'm reading Grune's Parsing Techniques and find it absolutely wonderful: easy to read, going into details and limits of the many parsing algos. Very cool! I'm playing with fully-backtracking recursive-descent parsers right now, to deal with ambiguous grammars and the small parser works beautifully. Hey, I just saw he gives the code on his website, nice! Now, on to LR. Nick, here I come. I'll at last know how Goldie works. Philippe
Re: Time for std.reflection
On Mon, Jul 23, 2012 at 2:43 PM, David Nadlinger s...@klickverbot.at wrote: [getting subclasses] You can't do that without breaking the module system – as long as a class is not final (and then it doesn't make much sense to ask for its subclasses anyway), somebody can always extend it in a module completely separate from the code making the query. To illustrate what I mean, let's assume you define a class Foo in a module A. The user imports A from a second module B, and potentially extends Foo there. Now, if it was possible to get all possible subclasses in A, this would lead to information leaking from B to A, while the import graph only allows the other direction. As a consequence, all kinds of issues related to order dependence, separate compilation, etc. would arise. Yes, I know. That would be a purely local question: from module A, what subclasses of class Foo do I see? Anyway, maybe I'm warped by CLOS.
Troubles with immutable arrays
After a discussion in D.learn started by someone else, after a
suggestion of mine Timon Gehr has added a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=8400
But the bug was fixed in the opposite way of what I was thinking.
The problem was that the length of global immutable arrays arrays
is seen as a compile-time constant.
Instead of fixing that, Issue 8400 has done the opposite, now
even the lenght of local immutable arrays is seen sometimes as a
compile-time constant, and example:
int[] foo(in int n) pure nothrow {
int[] a;
foreach (i; 0 .. n)
a ~= i * 10;
return a;
}
void main() {
import core.stdc.stdio: printf;
immutable int[] A = foo(5);
int[A.length] B;
printf(%zd\n, B.length);
}
The asm, compiled with -release:
_D4temp3fooFNaNbxiZAi comdat
L0: enter 018h,0
pushEBX
pushESI
mov dword ptr -018h[EBP],0
mov dword ptr -014h[EBP],0
mov dword ptr -010h[EBP],0
mov -0Ch[EBP],EAX
L1E:mov EAX,-010h[EBP]
cmp EAX,-0Ch[EBP]
jge L48
lea ECX,-010h[EBP]
mov EDX,[ECX]
lea EBX,[EDX*4][EDX]
add EBX,EBX
pushEBX
lea ESI,-018h[EBP]
pushESI
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
pushEAX
callnear ptr __d_arrayappendcT
add ESP,0Ch
inc dword ptr -010h[EBP]
jmp short L1E
L48:mov EDX,-014h[EBP]
mov EAX,-018h[EBP]
pop ESI
pop EBX
leave
ret
__Dmain comdat
L0: enter 018h,0
pushEBX
pushESI
push5
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
pushEAX
callnear ptr __d_arrayliteralTX
mov dword ptr [EAX],0
mov dword ptr 4[EAX],0Ah
mov dword ptr 8[EAX],014h
mov dword ptr 0Ch[EAX],01Eh
mov dword ptr 010h[EAX],028h
mov ECX,EAX
mov EBX,5
lea EDX,-018h[EBP]
xor EAX,EAX
mov [EDX],EAX
mov 4[EDX],EAX
mov 8[EDX],EAX
mov 0Ch[EDX],EAX
mov 010h[EDX],EAX
push5
mov ESI,offset FLAT:_DATA
pushESI
callnear ptr _printf
xor EAX,EAX
add ESP,010h
pop ESI
pop EBX
leave
ret
This code too compiles, so A is sometimes computed at run-time
and sometimes at compile-time:
int[] foo(in int n) pure nothrow {
int[] a;
foreach (i; 0 .. n)
a ~= i * 10;
return a;
}
void main() {
import core.stdc.stdio: printf;
int n = 5;
immutable int[] A = foo(n);
}
Now immutable arrays are sometimes seen as enums. I think this is
a problem. I think in D compile-time is run only if it's
evaluated in a context where compile-time values are required.
But now the situation is more muddy, because knowing n at
compile-time is not a way to ask A to be computed at compile-time.
Another problem is that compile-time arrays in many situations
are not efficient, they gets copied every time you use them, and
I think that __d_arrayliteralTX performs a heap allocation. So
now both enum and immutable arrays perform heap allocations every
time you use them, but only in some situations.
I think this is a messy situation, I think the fix for bug 8400
should be undone, and I think Issue 8400 should be fixed the
other way, turning global immutable arrays too into run-time
entities.
The bug was fixed by Hara and accepted by Walter, both of them
are very intelligent, so maybe I am just very wrong :-)
Bye,
bearophile
Re: of Conditional Implementation vs Assertive Input Validation
On Mon, Jul 23, 2012 at 1:44 PM, Chris NS ibisbase...@gmail.com wrote:
And for the curious, what I mean by embedding assertions in the conditions
is quite literally what it sounds like:
Range minPos ( Range ) ( Range R1 )
if( is( inputRange!Range ) )
assert( !isInfinite!Range, minPos cannot operate on infinite ranges. )
Would it be possible to create a If / Assert template that returns
(er, becomes) true if the condition is true, and static asserts if not
?
template Assert(bool condition, string message)
{
static if (condition)
enum Assert = true;
else
static assert(false, message);
}
void foo(T,U)(T t, U u) if (is(T == int) Assert!(isIntegral!U, U
must be an integer type))
{}
void main()
{
foo(1,a);
}
Seems to work (tm).
Getting a template parameter list
As an aside to a reflection-related train of thought, I tired
again to get a templated type's parameter list.
I mean, given
class C(T) { T t; }
Re: of Conditional Implementation vs Assertive Input Validation
On 23-Jul-12 17:29, Philippe Sigaud wrote:
On Mon, Jul 23, 2012 at 1:44 PM, Chris NS ibisbase...@gmail.com wrote:
And for the curious, what I mean by embedding assertions in the conditions
is quite literally what it sounds like:
Range minPos ( Range ) ( Range R1 )
if( is( inputRange!Range ) )
assert( !isInfinite!Range, minPos cannot operate on infinite ranges. )
Would it be possible to create a If / Assert template that returns
(er, becomes) true if the condition is true, and static asserts if not
?
Will explode every time a constraint is tested?
After all constraints do fail so that other function is picked up and
they are supposed to.
template Assert(bool condition, string message)
{
static if (condition)
enum Assert = true;
else
static assert(false, message);
}
void foo(T,U)(T t, U u) if (is(T == int) Assert!(isIntegral!U, U
must be an integer type))
{}
void main()
{
foo(1,a);
}
Seems to work (tm).
--
Dmitry Olshansky
Re: Getting a template parameter list
On Monday, 23 July 2012 at 13:32:54 UTC, Philippe Sigaud wrote:
As an aside to a reflection-related train of thought, I tired
again to get a templated type's parameter list.
I mean, given
class C(T) { T t; }
Drat, 'tab' is dangerous with the forum interface, sorry for that.
So given C above and
auto c = new C!(int)();
I want a template that, given typeof(c), gives me back 'C' and
'int'.
is() is our friend here, notably the new T... extension:
import std.typetuple;
template Composition(T) if (isComposite!T)
{
static if (is(T comp == Name!(U), alias Name, U) || is (T
comp == Name!(U), alias Name, U...))
alias TypeTuple!(Name, U) Composition;
}
(isComposite!T is the same check with is())
Works beautifully:
auto t = tuple(1,abc, 'c');
writeln(Composition!(typeof(t)).stringof); // (Tuple(Specs...),
int, string, char)
So, I get Tuple(Specs...) (the template name) and the
arguments. Nice!
Except, this does not work for 2-args templates. I thought the
U... branch would get them, but apparently, U... means 'with a
template param tuple' very strictly. No problem, I'll just add
the 2, 3 and 4-args cases, that should be enough.
template Composition(T) if (isComposite!T)
{
static if (is(T comp == Name!(U), alias Name, U) || is (T
comp == Name!(U), alias Name, U...))
alias TypeTuple!(Name, U) Composition;
else static if (is(T comp == Name!(U,V), alias Name, U, V))
alias TypeTuple!(Name, U,V) Composition;
else static if (is(T comp == Name!(U,V,W), alias Name, U, V,
W))
alias TypeTuple!(Name, U,V,W) Composition;
...
}
(and isComposite accordingly).
Right. Except, this only gets template instantiations with pure
types as parameters. Things like std.algorithm.map which take a
function by name are out.
OK... So, I'll add also alias overloads. Hmm, Pure Type / Alias :
2 possibilities, so for 3 args that's 8 different tests to do + 4
for 2-params, + 2 for the single param and the tuple...
Except, you can have a tuple also in 2-params and 3-params
templates.
Also, what about value template parameters? I tested, this does
not work when passed strings or ints, or whatever. I should test
for them also.
Argh, so it's more 10 different possibilities per slot, the n-th
power for n args.
No way am I generating a template with more than a thousand(!)
is() tests in it!
Can someone offer me some advice on this? My old version that
cheated with the type .stringof suddenly seems so much better.
Philippe
Re: of Conditional Implementation vs Assertive Input Validation
On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Will explode every time a constraint is tested? After all constraints do fail so that other function is picked up and they are supposed to. Damn, you're right.
Re: of Conditional Implementation vs Assertive Input Validation
On Mon, 23 Jul 2012 15:49:43 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
Will explode every time a constraint is tested?
After all constraints do fail so that other function is picked up and
they
are supposed to.
Damn, you're right.
To be fair, it explodes as often as the if (isInputRange!T){static
assert(!isInfinite!T);} does.
--
Simen
Re: Optional name mangling
Stuart stu...@gmx.com wrote in message news:hcrszoaeyauztrlpi...@forum.dlang.org... Correct me if I'm wrong, but isn't it only C++ that does mangling? You're wrong.
Re: Getting a template parameter list
On Mon, 23 Jul 2012 15:46:37 +0200, Philippe Sigaud philippe.sig...@gmail.com wrote: Can someone offer me some advice on this? My old version that cheated with the type .stringof suddenly seems so much better. This was filed as bug 3608[1], but that report was insufficiently specific, and so T... matching both a TemplateParameterList and a variadic TemplateParameter apparently did not make it into the patch. I'm unsure if I should mark the old bug report as reopened, or file a new one. [1]: http://d.puremagic.com/issues/show_bug.cgi?id=3608 -- Simen
Re: of Conditional Implementation vs Assertive Input Validation
On 23-Jul-12 18:07, Simen Kjaeraas wrote:
On Mon, 23 Jul 2012 15:49:43 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
Will explode every time a constraint is tested?
After all constraints do fail so that other function is picked up and
they
are supposed to.
Damn, you're right.
To be fair, it explodes as often as the if (isInputRange!T){static
assert(!isInfinite!T);} does.
Right. It's just I did something similar to Philippe stuff previously
and this somehow was an unpleasant surprise for me.
--
Dmitry Olshansky
Random sampling next steps
Hello all,
At the risk of sounding like a one-trick pony, some thoughts on RandomSample and
what remains to be done with it.
Besides algorithmic improvements, the recent updates from Martin Nowak and
myself have fixed a couple of key bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=7936
http://d.puremagic.com/issues/show_bug.cgi?id=8314
... but we still have a couple of important outstanding issues:
http://d.puremagic.com/issues/show_bug.cgi?id=7067
http://d.puremagic.com/issues/show_bug.cgi?id=8247
The solution here would seem to be identical and involve not changing
RandomSample but changing the random number generators to being reference types;
cf. discussion in those bug reports, and also here:
http://forum.dlang.org/thread/4fd735eb.70...@webdrake.net
This is a controversial issue as it would involve a breaking change to D's RNG
design, but broadly speaking seems like a necessary breaking change to avoid
these kinds of issues cropping up consistently across various different
applications. Indeed, it seems likely that only flawed code, involving passing
RNG by value, would have an issue with this change, and there may also be
positive effects for future development of other parts of std.random.
However, the issue I'd like to dwell on here is the one raised by Craig
Dillabaugh in comments on my blog. The current RandomSample implementation
covers only the case where the total number of items to pick from is known in
advance. In other words, either your input range needs hasLength!R == true or
you need to manually specify the total number of items when calling randomSample:
auto randomSample(R)(R r, size_t n, size_t total)
if(isInputRange!R)
{
return RandomSample!(R, void)(r, n, total);
}
auto randomSample(R)(R r, size_t n)
if(isInputRange!R hasLength!R)
{
return RandomSample!(R, void)(r, n, r.length);
}
... and similarly in the constructor of RandomSample:
static if (hasLength!R)
this(R input, size_t howMany)
{
this(input, howMany, input.length);
}
this(R input, size_t howMany, size_t total)
{
_input = input;
_available = total;
_toSelect = howMany;
enforce(_toSelect = _available);
_first = true;
}
But what if the total number of items is not known in advance? E.g. if you are
reading a file, line by line, or reading records from a tape; you may know the
total is finite, but you don't know what it actually _is_.
There are dedicated algorithms for this, via the technique known as reservoir
sampling. Knuth lists Algorithm R; Vitter has defined an improved technique,
Algorithm Z. These should be fairly easy to implement in D, but the question is
how to integrate them with the existing random sampling functionality.
The simplest way would be to just implement an additional struct and function,
say, RandomReservoirSample and randomReservoirSample. However, I was wondering
about a setup where there is a single interface that looks at the input range
and other data you have provided and makes an intelligent choice of the optimal
algorithm. It's this I'd like advice on.
One solution would be to have two different underlying structs which are
selected depending on provided data:
auto randomSample(R)(R r, size_t n)
if(isInputRange!R hasLength!R)
{
return RandomSample!(R, void)(r, n, r.length);
}
auto randomSample(R)(R r, size_t n)
if(isInputRange!R !hasLength!R)
{
return RandomReservoirSample!(R, void)(r, n);
}
... but doing something similar within RandomSample doesn't seem so easy. Why?
Because the static if()s that you'd require within the struct would not depend
just on whether hasLength!R == true, but also on whether you'd passed a size_t
total to the constructor. I'm not sure how to factor in the latter case, even
though it's clearly a compile-time issue. Can anyone advise?
Basically, I want to be able to say: static if(!hasLength!R
no_total_was_passed) then certain functions or certain variables are or aren't
defined.
I also think it would be a good idea for the reservoir sampling technique to
emit a warning when in debug mode, to prompt the user to be _sure_ that they
can't specify the total number of points to sample from. Is there a recommended
method of doing something like this?
Alternatively, would people prefer to entirely separate the known-total and
unknown-total sampling methods entirely, so the choice is always manual?
Finally, if hasLength!R == false, is there any way of guaranteeing that the
input range is still going to be ultimately finite? There could be some very
nasty worst-case behaviour in the case of infinite ranges.
I'm asking this here rather than d-learn as it's related to design choices for
Phobos, but I'll happily move the discussion over if necessary.
Thanks and best wishes,
-- Joe
feature request: with(var decl) {}
I was just thinking about porting a javascript function to
D that takes an object of params:
function foo(args) { ... }
foo( { closeButton : false, width : 200 } );
In D, I figured I'd make args a struct:
struct FooArgs {
bool closeButton = true; // the default is for it to be there
int width = 600;
}
void foo(FooArgs args) { ... }
And, of course, this works, but it was leaving a declared
variable around and can be somewhat repetitive. But first
I tried making it look kinda like the JS:
FooArgs args = { closeButton: false };
foo(args);
But, that style struct initializer doesn't respect the default
values. Here, width == 0. No good.
So, then, well, that's OK, I'll just write it out:
FooArgs args;
args.closeButton = false;
foo(args);
There we go, not too bad at all. We can kill some repetition
of args with the with() {} statement. Great!
But, what if I have another call later? I don't want that args
sticking around.
FooArgs args;
// ...
foo(args);
BarArgs args; // error, args already declared
No prob, let's scope it! I tried:
with(FooArgs args) {
closeButton = false;
foo(args);
}
// can redeclare another args here if you want
But it didn't work. It is with(symbol) or with(expression)
in the spec.
Would it work to also allow with(decl)? It seems to me that
it should be ok... kinda similar to the currently allowed
if(auto a = foo()) { /* use a here */ }
So we're just extending that same idea out to the with statement
too.
Re: feature request: with(var decl) {}
On 07/23/12 16:37, Adam D. Ruppe wrote:
But it didn't work. It is with(symbol) or with(expression)
in the spec.
Would it work to also allow with(decl)? It seems to me that
it should be ok... kinda similar to the currently allowed
if(auto a = foo()) { /* use a here */ }
So we're just extending that same idea out to the with statement
too.
The more general form would be to make variable declaration an expression. I'm
not sure if that causes any ambiguity, parsing-wise, but it allows other neat
things as well, like while(vardecl) and if (decl1 condition).
Re: of Conditional Implementation vs Assertive Input Validation
On 7/23/12 7:10 AM, monarch_dodra wrote: [snip] How do you feel about assertive input validation vs conditional implementation? Is this something you'd like to see more of in algorithm? The assertive input validation has the problem it prevents an overload outside of std.algorithm from working. I think we should focus here on the compiler giving better information about which part of the Boolean constraint failed. Andrei
Re: Let's stop parser Hell
On 7/23/12 9:22 AM, Philippe Sigaud wrote: On Thu, Jul 5, 2012 at 10:00 PM, Tobias Pankrathtob...@pankrath.net wrote: If you are interested in parsing, than I wouldn't recommend the dragon book, but this one It really is an awesome book. This little post to say a big 'Thanks' to Tobias. I'm reading Grune's Parsing Techniques and find it absolutely wonderful: easy to read, going into details and limits of the many parsing algos. Very cool! I'm playing with fully-backtracking recursive-descent parsers right now, to deal with ambiguous grammars and the small parser works beautifully. Hey, I just saw he gives the code on his website, nice! Now, on to LR. Nick, here I come. I'll at last know how Goldie works. When will we see the fruit of that all in the form of D libraries? Andrei
Re: feature request: with(var decl) {}
On Monday, 23 July 2012 at 14:46:30 UTC, FeepingCreature wrote: The more general form would be to make variable declaration an expression. Right, and that would be pretty amazing, but it would probably be too hard to do in D today...
Re: Let's stop parser Hell
On Monday, 23 July 2012 at 13:22:47 UTC, Philippe Sigaud wrote: On Thu, Jul 5, 2012 at 10:00 PM, Tobias Pankrath tob...@pankrath.net wrote: If you are interested in parsing, than I wouldn't recommend the dragon book, but this one It really is an awesome book. This little post to say a big 'Thanks' to Tobias. I'm reading Grune's Parsing Techniques and find it absolutely wonderful: easy to read, going into details and limits of the many parsing algos. Very cool! Yes, I'm also reading it and find it amusingly high-quality.
Re: Troubles with immutable arrays
Oh, no. I've accidentally done the *fix*, even though that is contrary
to my own claim.
I don't like the cross-talk of compile-time and run-time variables.
An related issue is bug 3449, but it has been opposed by Walter.
http://d.puremagic.com/issues/show_bug.cgi?id=3449
A small example of bug 3449:
void main()
{
struct Foo1 { const int bar; }
pragma(msg, Foo1.sizeof); // Prints 4
Foo1 foo1;
auto p1 = foo1.bar;// Succeeds to compile, as excepced.
struct Foo2 { const int bar = 123; }
pragma(msg, Foo2.sizeof); // Prints 1, not 4
Foo2 foo2;
auto p2 = foo2.bar;// Error: constant 123 is not an lvalue
}
Why cannot get address of foo2.bar?
The answer is: compiler makes Foo2.bar a manifest constant, because
its type is not mutable and has an initializer.
---
With current dmd, *all* of variable declarations, that has non mutable
type and initializer, are _speculatively_ interpreted in compile time
(== CTFE-ed). If it is succeeds, the declaration will be treated as
same as manifest constant. That is the reason of you explained *bug*
and bug 3449.
I think the *implicit interpretation* is inherited from D1, and if go
back further, will reach to C++ constant variable.
BUT, in D2, we have the 'enum' declaration, which express the
declaration is really manifest constant.
So, the muddy interpretation just confuses many D user's, and less benefit.
I think we should separate run-time variable declarations and compile
time ones, to moderate the leaning curve.
Regards.
Kenji Hara
2012/7/23 bearophile bearophileh...@lycos.com:
After a discussion in D.learn started by someone else, after a suggestion of
mine Timon Gehr has added a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=8400
But the bug was fixed in the opposite way of what I was thinking.
The problem was that the length of global immutable arrays arrays is seen as
a compile-time constant.
Instead of fixing that, Issue 8400 has done the opposite, now even the
lenght of local immutable arrays is seen sometimes as a compile-time
constant, and example:
int[] foo(in int n) pure nothrow {
int[] a;
foreach (i; 0 .. n)
a ~= i * 10;
return a;
}
void main() {
import core.stdc.stdio: printf;
immutable int[] A = foo(5);
int[A.length] B;
printf(%zd\n, B.length);
}
The asm, compiled with -release:
_D4temp3fooFNaNbxiZAi comdat
L0: enter 018h,0
pushEBX
pushESI
mov dword ptr -018h[EBP],0
mov dword ptr -014h[EBP],0
mov dword ptr -010h[EBP],0
mov -0Ch[EBP],EAX
L1E:mov EAX,-010h[EBP]
cmp EAX,-0Ch[EBP]
jge L48
lea ECX,-010h[EBP]
mov EDX,[ECX]
lea EBX,[EDX*4][EDX]
add EBX,EBX
pushEBX
lea ESI,-018h[EBP]
pushESI
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
pushEAX
callnear ptr __d_arrayappendcT
add ESP,0Ch
inc dword ptr -010h[EBP]
jmp short L1E
L48:mov EDX,-014h[EBP]
mov EAX,-018h[EBP]
pop ESI
pop EBX
leave
ret
__Dmain comdat
L0: enter 018h,0
pushEBX
pushESI
push5
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
pushEAX
callnear ptr __d_arrayliteralTX
mov dword ptr [EAX],0
mov dword ptr 4[EAX],0Ah
mov dword ptr 8[EAX],014h
mov dword ptr 0Ch[EAX],01Eh
mov dword ptr 010h[EAX],028h
mov ECX,EAX
mov EBX,5
lea EDX,-018h[EBP]
xor EAX,EAX
mov [EDX],EAX
mov 4[EDX],EAX
mov 8[EDX],EAX
mov 0Ch[EDX],EAX
mov 010h[EDX],EAX
push5
mov ESI,offset FLAT:_DATA
pushESI
callnear ptr _printf
xor EAX,EAX
add ESP,010h
pop ESI
pop EBX
leave
ret
This code too compiles, so A is sometimes computed at run-time and sometimes
at compile-time:
int[] foo(in int n) pure nothrow {
int[] a;
foreach (i; 0 .. n)
a ~= i * 10;
return a;
}
void main() {
import core.stdc.stdio: printf;
int n = 5;
immutable int[] A = foo(n);
}
Now immutable arrays are sometimes seen as enums. I think this is a problem.
I think in D compile-time is run only if it's evaluated in a context where
compile-time values are required. But now the situation is more muddy,
because knowing n at compile-time is not a way to ask A to be computed at
compile-time.
Another problem is that compile-time arrays in many situations are not
efficient, they gets copied every time you use them, and I think that
__d_arrayliteralTX performs a heap allocation. So now both enum and
immutable arrays perform heap allocations every time you use them, but only
in some situations.
I
Re: Formal request to remove put(OutRange, RangeOfElements)
Maybe I should put this request elsewhere? I'm not sure if there is a place where I should put this? I know this is not a very exciting issue, but I think it is a very important to resolve, preferably sooner than later. Maybe I'll try to help kick start this by listing all the modules that would need to be changed?
Re: feature request: with(var decl) {}
Le 23/07/2012 16:37, Adam D. Ruppe a écrit : I was just thinking about porting a javascript function to D that takes an object of params: Let's not add another special case for the declaration can be used here instead of an expression. This is already the case in if and it will proliferate. The real need here is to allow variable declaration to be used as expressions. And functions too as they are first class citizens now. This reduces special cases instead of adding new one, and give a much greater opportunity for expressiveness in the language.
Re: feature request: with(var decl) {}
Le 23/07/2012 16:46, FeepingCreature a écrit :
On 07/23/12 16:37, Adam D. Ruppe wrote:
But it didn't work. It is with(symbol) or with(expression)
in the spec.
Would it work to also allow with(decl)? It seems to me that
it should be ok... kinda similar to the currently allowed
if(auto a = foo()) { /* use a here */ }
So we're just extending that same idea out to the with statement
too.
The more general form would be to make variable declaration an expression. I'm not sure
if that causes any ambiguity, parsing-wise, but it allows other neat things as well,
like while(vardecl) and if (decl1 condition).
With the current grammar, it is difficult, because declarations are
statements.
Re: Random sampling next steps
Joseph Rushton Wakeling , dans le message (digitalmars.D:172997), a
écrit :
In other words, either your input range needs hasLength!R == true or
you need to manually specify the total number of items when calling
randomSample:
But what if the total number of items is not known in advance? E.g. if you
are
reading a file, line by line, or reading records from a tape; you may know
the
total is finite, but you don't know what it actually _is_.
[snip]
... but doing something similar within RandomSample doesn't seem so easy.
Why?
Because the static if()s that you'd require within the struct would not
depend
just on whether hasLength!R == true, but also on whether you'd passed a
size_t
total to the constructor.
Why not using takeExactly ? this is the standard way select from a
subset of the original range. I wouldn't even have provided the overload
with 3 arguments, the user being able to use takeExactly when necessary
(which could be advised in the doc in case the user doesn't know).
struct RandomSample(R) if (isInputRange!R hasLength!R)
{
...// always use r.length, never total/available
}
auto randomSample(R)(R r, size_t n, size_t total)
if(isInputRange!R)
{
return randomSample!(R, void)(takeExactly(r, total), n);
}
struct RandomSample(R) if(isInputRange!R !hasLength!R)
{
...// always reservoir random sample
}
There is no more issue here.
I also think it would be a good idea for the reservoir sampling technique to
emit a warning when in debug mode, to prompt the user to be _sure_ that they
can't specify the total number of points to sample from. Is there a
recommended
method of doing something like this?
I don't think library polluting compiler warnings is recommended.
Alternatively, would people prefer to entirely separate the known-total and
unknown-total sampling methods entirely, so the choice is always manual?
RandomSample is a lazy range. RandomReservoirSample is not, and has a
completely different implementation. IMHO, there is a fundamental
difference that justifies to have a separate function with a different
name.
Finally, if hasLength!R == false, is there any way of guaranteeing that the
input range is still going to be ultimately finite? There could be some very
nasty worst-case behaviour in the case of infinite ranges.
IsInfinite!Range.
However, a finite range could return false on empty indefinitely, would
the implementer of the range just forget to make empty an enum, or the
user meet a corner case (e.g. repeat(1).until(2)). But that's a general
problem, that would make most eager algorithm result in an infinite
loop, starting with array and copy...
--
Christophe
Re: Just where has this language gone wrong?
Am 23.07.2012 14:49, schrieb Stuart: On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote: C++ is living in the 70's. Precisely what I have been thinking. It's a loose wrapper around assembly, nothing more. Certainly not the high-level language it's touted as. Only due to the lack of modules. Everything else is a pretty modern language I would say. Personally as I referred here in multiple threads I don't have any big issues dealing with C++, but maybe that is just me. -- Paulo
Re: Formal request to remove put(OutRange, RangeOfElements)
monarch_dodra , dans le message (digitalmars.D:173005), a écrit : Maybe I should put this request elsewhere? I'm not sure if there is a place where I should put this? I know this is not a very exciting issue, but I think it is a very important to resolve, preferably sooner than later. Maybe I'll try to help kick start this by listing all the modules that would need to be changed? You can fill a bug report. assert(isOutputRange!typeof(r), typeof(e) !output.r); output.put(e); failing on the second line is worthy of attention. And it makes fill fail IIRC. -- Christophe
DMD 2.1.0?
Given: - The many differences between dmd 2.059 and 2.060alpha, and the amount of time passed since the release of 2.059; - The fact that there are some 2.060alpha regressions to be fixed still, so dmd 2.060 is not coming out tomorrow; - And the recent idea of introducing stable dmd releases that include many patches despite not being really a v.2.061 (see the Stable D Releases! in D.announce); - That I think a languageNumber.majorVersion.revision numbering scheme is better, more widespread and more useful (where languageNumber is 1, 2 and maybe 3, a change in majorVersion means something is changed in the language and this calls for changes in user code and this is the point where the stable D releases must include all the patches of the main trunk, and revision means just bug fixes and tiny backwards-compatible enhancements that are not necessarily included in the stable D release) (See: http://en.wikipedia.org/wiki/Software_versioning ). Then I suggest to call the next release dmd 2.1.0 :-) And maybe in such 2.1.0 it's better to deprecate the features marked as future here: http://dlang.org/deprecate.html In a Bugzilla entry (6277) I have also suggested another idea (maybe fit for dmd 2.1.0 still) to improve the evolvability of the D language: beside using -d (deprecated features) another way to face those problems is to use an idea from Python, a switch like -future that activates language features that will be introduced in future (this also means the -property flag gets moved into -future and removed, so the total amount of dmd flags doesn't change). Bye, bearophile
Re: Troubles with immutable arrays
Thank you for your answer and your understanding, Hara. I hope you will improve the situation. Regarding this issue: http://d.puremagic.com/issues/show_bug.cgi?id=3449 Maybe Walter is wrong about it, so I suggest people to express their opinion. Bye, bearophile
Re: Computed gotos on Reddit
deadalnix:
The presented example is insanely unsafe. By giving invalid
input, you can basically branch randomly.
The check added by the switch is what is required to make it
safe, so it isn't faster at the end.
The case in the article isn't very strong.
Thank you for your answer. We have not yet designed how D
computed gotos are, both in syntax and semantics. This means that
maybe there are ways to make them a little safer, in non-release
mode.
Part of the GCC-C code in the article was:
static void* dispatch_table[] = {
do_halt, do_inc, do_dec, do_mul2,
do_div2, do_add7, do_neg};
#define DISPATCH() goto *dispatch_table[code[pc++]]
In D there are no preprocessor macros and the array bounds are
enforced at run-time, this avoids some possible bugs of similar
code.
Also, instead of void* maybe a different type can be introduced,
so only label addresses of the current function can be put in
dispatch_table and pointer variables given to goto. This
statically avoids some other possible bugs.
It's true that in the end computed gotos are unsafe, you
generally need to validate the bytecode/state transition before
feeding them to the computed goto, and in D (unlike GCC-C) you
are able to forbid the usage of computed gotos in @safe
functions/methods. This doesn't avoid bugs, but helps contain
them in delimited places. We have the @safe/@trusted/@system for
a purpose.
In D modules like std.reflection suggested by Andrei are useful,
because D is usable to write lot of high-level code too, I use a
highly functional D style in some little D scripts. But D is
also a system language, and sometimes I desire to use it for
tasks where C is used. GCC has computed gotos since many years
(and Clang supports them) and as you see in the linked article
some very common language interpreters you see around use
computed gotos if the C compiler supports them. This is not a
must-have feature for D, but dismissing it just because it's not
safe is a bad idea.
Bye,
bearophile
Re: Optional name mangling
On Monday, 23 July 2012 at 14:08:39 UTC, Daniel Murphy wrote: Stuart stu...@gmx.com wrote in message news:hcrszoaeyauztrlpi...@forum.dlang.org... Correct me if I'm wrong, but isn't it only C++ that does mangling? You're wrong. Fair enough. But there are still times when we need a version of export that doesn't mangle.
Re: Optional name mangling
On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote: Fair enough. But there are still times when we need a version of export that doesn't mangle. No. This is even impossible to do with some compiler backends. For example, LLVM on OS X automatically appends an underscore to the beginning of symbol names, because every C function has an »extra« underscore at the beginning there. David
Re: DMD 2.1.0?
On Mon, 23 Jul 2012 09:30:21 -0700, bearophile bearophileh...@lycos.com wrote: Given: - The many differences between dmd 2.059 and 2.060alpha, and the amount of time passed since the release of 2.059; - The fact that there are some 2.060alpha regressions to be fixed still, so dmd 2.060 is not coming out tomorrow; - And the recent idea of introducing stable dmd releases that include many patches despite not being really a v.2.061 (see the Stable D Releases! in D.announce); - That I think a languageNumber.majorVersion.revision numbering scheme is better, more widespread and more useful (where languageNumber is 1, 2 and maybe 3, a change in majorVersion means something is changed in the language and this calls for changes in user code and this is the point where the stable D releases must include all the patches of the main trunk, and revision means just bug fixes and tiny backwards-compatible enhancements that are not necessarily included in the stable D release) (See: http://en.wikipedia.org/wiki/Software_versioning ). Then I suggest to call the next release dmd 2.1.0 :-) And maybe in such 2.1.0 it's better to deprecate the features marked as future here: http://dlang.org/deprecate.html In a Bugzilla entry (6277) I have also suggested another idea (maybe fit for dmd 2.1.0 still) to improve the evolvability of the D language: beside using -d (deprecated features) another way to face those problems is to use an idea from Python, a switch like -future that activates language features that will be introduced in future (this also means the -property flag gets moved into -future and removed, so the total amount of dmd flags doesn't change). Bye, bearophile This may pose an issue to the dlang-stable project ... Particularly I think we all are still trying to figure out just how it will work. At this point the dlang-stable repos are just forks of D from June 16th, it's essentially just a snapshot of 2.060. Our plan was to reset the repos to 2.060 to clean out any mistakes made during the learning process and then use 2.060 as a the base point. After that a 2.1.61 makes a LOT of sense, at least for dlang-stable. :-) However, if you want to make the argument that the June 16 snapshot of 2.060 is a good enough starting point, i'm all ears. :-) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Let's stop parser Hell
On Monday, 23 July 2012 at 13:22:47 UTC, Philippe Sigaud wrote: On Thu, Jul 5, 2012 at 10:00 PM, Tobias Pankrath tob...@pankrath.net wrote: If you are interested in parsing, than I wouldn't recommend the dragon book, but this one It really is an awesome book. This little post to say a big 'Thanks' to Tobias. I'm reading Grune's Parsing Techniques and find it absolutely wonderful: easy to read, going into details and limits of the many parsing algos. Very cool! I'm glad that you like it.
Re: DMD 2.1.0?
On Monday, 23 July 2012 at 16:30:23 UTC, bearophile wrote: Given: [...] - That I think a languageNumber.majorVersion.revision numbering scheme is better, more widespread and more useful (where languageNumber is 1, 2 and maybe 3, a change in majorVersion means something is changed in the language and this calls for changes in user code and this is the point where the stable D releases must include all the patches of the main trunk, and revision means just bug fixes and tiny backwards-compatible enhancements that are not necessarily included in the stable D release) (See: http://en.wikipedia.org/wiki/Software_versioning ). Then I suggest to call the next release dmd 2.1.0 :-) [...] It's not majorVersion that is missing from the current scheme, it's revision. There already was a dmd 2.1.0: http://dlang.org/changelog.html#new2_001
Re: DMD 2.1.0?
On 7/23/12, bearophile bearophileh...@lycos.com wrote: - The many differences between dmd 2.059 and 2.060alpha Is there a changelog somewhere? The DMD changelog seems to be a year old on github.
Re: DMD 2.1.0?
On 7/23/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 7/23/12, bearophile bearophileh...@lycos.com wrote: - The many differences between dmd 2.059 and 2.060alpha Is there a changelog somewhere? The DMD changelog seems to be a year old on github. Also I'm getting a JS error on the changelog page: Hyphenator.js says: An Error ocurred: Not enough arguments
Re: DMD 2.1.0?
anonymous: It's not majorVersion that is missing from the current scheme, it's revision. There already was a dmd 2.1.0: http://dlang.org/changelog.html#new2_001 60 major versions is a lot, but maybe you are right. Then what's a good numbering for the next dmd? Maybe DMD 2.60.0 ? Bye, bearophile
Re: Computed gotos on Reddit
On 7/22/2012 4:35 PM, bearophile wrote: Computed gotos are useful to write interpreters. Interpreters are a niche but important purpose of system languages like D. Computed gotos are also useful to implement certain finite state machines (like some used in computational biology). D already has it: http://dlang.org/statement.html#FinalSwitchStatement
Re: of Conditional Implementation vs Assertive Input Validation
On 2012-07-23 16:47, Andrei Alexandrescu wrote:
The assertive input validation has the problem it prevents an overload
outside of std.algorithm from working.
I think we should focus here on the compiler giving better information
about which part of the Boolean constraint failed.
I would like to have something like this:
constraint InputRange (Range)
{
alias ElementType!(Range.init) E;
@property bool empty ();
void popFront ();
@property E front ();
}
constraint ForwardRange (Range) : ForwardRange!(Range)
{
E save ();
}
constraint BidirectionalRange (Range) : ForwardRange!(Range)
{
void popBack ();
@property E back ();
@property E front ();
}
It would be even better if the Range parameter and the ElementType could
be handled automatically:
constraint BidirectionalRange : ForwardRange
{
void popBack ();
@property ElementType back ();
@property ElementType front ();
}
And then to use the constraints, like this:
auto filterBidirectional (alias pred, Range :
BidirectionalRange!(Range)) (Range range);
Or even better if this would be possible:
auto filterBidirectional (alias pred) (BidirectionalRange range);
I know that others have had similar ideas. In these cases I think the
compiler should be able to give clear and proper error messages when
something fails to match because now the range constraints/interfaces
have names. Something like Foo doesn't match BidirectionalRange or
similar.
--
/Jacob Carlborg
dmd: template.c:5540: Identifier* TemplateInstance::genIdent(Objects*): Assertion `global.errors' failed.
I hope someone will put this on bugzilla dmd loops endlessly on this code: import std.typecons; string bug(T..., U : tuple!T)(tuple!T t); dmd aborts on this code: import std.typecons; string bug(T, U : tuple!T)(tuple!T t); enum e = bug(tuple!int);
Re: of Conditional Implementation vs Assertive Input Validation
On Monday, 23 July 2012 at 19:57:42 UTC, Jacob Carlborg wrote:
[snip]
I know that others have had similar ideas. In these cases I
think the compiler should be able to give clear and proper
error messages when something fails to match because now the
range constraints/interfaces have names. Something like Foo
doesn't match BidirectionalRange or similar.
My fear is that no matter how you look at it, the compiler just
doesn't know which overload you want to call. If the compiler
could generate messages about why each overload was not
satisfactory, and it would have then to generate messages about
each and every possible overload, including the ones that you
obviously didn't want. Things would be better, but probably
over-verbose :/
My thought was not to remove conditional implementations
entirely, but rather to compliment them:
I think, for example, this would be perfect for equal:
Takes two input ranges, and compares them with pred:
Notice that the english input condition here is merely two input
ranges. If the range elements don't actually compare, it does
not mean you did not fulfill the input contract, but rather
that you did not fulfill the implementation requirements.
equal(alias pred = a == b, R1, R2)(R1 range1, R2 range2)
if (isInputRange!R1 isInputRange!R2)
{
assert(is(typeof(BinaryPred!pred(r1.front, r2.front))), equal:
elements are not predicate comparable);
...
}
On Monday, 23 July 2012 at 14:47:50 UTC, Andrei Alexandrescu
wrote:
The assertive input validation has the problem it prevents an
overload outside of std.algorithm from working.
I think we should focus here on the compiler giving better
information about which part of the Boolean constraint failed.
Andrei
That is true, but then again, a certain level of ambiguity is a
good thing®. The compiler choosing too eagerly which function
you want to call based on obscure conditional implementations is
dangerous (IMO).
For example, if somebody else provided an equal which operated
on two input ranges, and took a unary predicated, and then used
the result of the unary predicate to compare the elements, I sure
as hell wouldn't it to be disambiguated without my explicit
consent.
If somebody writes a fill that can operate on input
(non-forward, non-infinite) ranges, I WANT the ambiguity.
I think the above gives a good balance of both approaches: The
conditional implementation is enough to *roughly* define what the
function operates on, while giving enough leeway for
non-ambiguous overloads. Once the compiler has *chosen* the
implementation though, then more thorough input validation can
kick in.
That's my take on it anyways.
Re: Just where has this language gone wrong?
On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
Am 23.07.2012 14:49, schrieb Stuart:
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky
wrote:
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper
around
assembly, nothing more. Certainly not the high-level language
it's touted as.
Only due to the lack of modules.
Everything else is a pretty modern language I would say.
Hardly. No RTTI. No GC. No properties. No events. No closures. No
extension methods. No interfaces. No writable references.
I can live without a GC; and interfaces can be simulated using
pure virtual base classes; but all the others are standard in
pretty much any modern language and impossible to reproduce in
C++.
Incidentally, it'd be really handy to have anonymous tuples in D.
Not many languages let you do that. For example:
tuple!(int, float) fn() { ... }
int a;
float b;
(a, b) = fn();
auto (c, d) = fn();
Saves us having to create a struct for every goddamn little
function; or using tuples directly, which means we have to refer
to variables like .value1 and .value2 instead of something
meaningful.
Re: dmd: template.c:5540: Identifier* TemplateInstance::genIdent(Objects*): Assertion `global.errors' failed.
On Mon, 23 Jul 2012 22:21:30 +0200 Lukasz wrzo...@gmail.com wrote: I hope someone will put this on bugzilla dmd loops endlessly on this code: import std.typecons; string bug(T..., U : tuple!T)(tuple!T t); dmd aborts on this code: import std.typecons; string bug(T, U : tuple!T)(tuple!T t); enum e = bug(tuple!int); You can put it there: http://d.puremagic.com/issues/
Re: Optional name mangling
On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote: On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote: Fair enough. But there are still times when we need a version of export that doesn't mangle. No. This is even impossible to do with some compiler backends. For example, LLVM on OS X automatically appends an underscore to the beginning of symbol names, because every C function has an »extra« underscore at the beginning there. I mean for importing. The functions in shlwapi.lib don't have underscores. We ought to have some kind of syntax for importing them without faffing about with .def files. Surely it must be possible?
Re: Just where has this language gone wrong?
On Monday, 23 July 2012 at 20:51:19 UTC, Stuart wrote: Incidentally, it'd be really handy to have anonymous tuples in D. Or perhaps I should've said named tuples. I dunno what the correct term might be. All I know is, I've only seen it in one or two obscure languages, and I've always wished .NET had it.
Re: Just where has this language gone wrong?
On Mon, 23 Jul 2012 22:51:19 +0200, Stuart stu...@gmx.com wrote:
Saves us having to create a struct for every goddamn little function; or
using tuples directly, which means we have to refer to variables like
.value1 and .value2 instead of something meaningful.
You mean like this?
Tuple!(float, x, float, y) bar() {
return typeof(return)( 0.0, 0.0 );
}
auto xCoord = bar().x;
I dislike the typeof(return) in there, as assignment between tuples with
and without named fields works perfectly. Bring me the sky, Walter?
--
Simen
Re: Formal request to remove put(OutRange, RangeOfElements)
On Monday, July 23, 2012 17:33:07 monarch_dodra wrote: Maybe I should put this request elsewhere? I'm not sure if there is a place where I should put this? I know this is not a very exciting issue, but I think it is a very important to resolve, preferably sooner than later. Maybe I'll try to help kick start this by listing all the modules that would need to be changed? If you've found a bug, then report it bugzilla. If you have an issue that needs discussion, then this is the right place. It's just that you don't always get people responding, especially if it's a complicated topic (and the fact that it's summer right now probably doesn't help due to an increased number of people on vacation). Personally, I intend to read through this and respond, but it's the sort of thing that obviously needs to be read through and thought through carefully before discussing, and I haven't had the chance to do that yet. - Jonathan M Davis
Re: Just where has this language gone wrong?
On Mon, 23 Jul 2012 22:51:19 +0200 Stuart stu...@gmx.com wrote: On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote: Am 23.07.2012 14:49, schrieb Stuart: On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote: C++ is living in the 70's. Precisely what I have been thinking. It's a loose wrapper around assembly, nothing more. Certainly not the high-level language it's touted as. Only due to the lack of modules. Everything else is a pretty modern language I would say. Hardly. No RTTI. No GC. No properties. No events. No closures. No extension methods. No interfaces. No writable references. Null-terminated strings. Preprocessor. No reflection. Effectively undefined sizes for primitive types. Undefined behavior galore. Neither default initialization nor enforced initialization before variable usage. No reference types (Foo isn't what I mean). Horrendous type syntax for mixed arrays/ptrs or functions ptrs, etc. No forward references (or at least very limited). And a grammar that forces compilation to be very, very slow. And a lot more still that's lacking if you don't count C++11 which isn't widely supported yet (ex: foreach, basic type inference). And the fact that static analysis tools are as super useful as they are is plenty proof alone that the language itself is WAAAY behind the curve.
Re: Computed gotos on Reddit
Walter Bright: D already has it: http://dlang.org/statement.html#FinalSwitchStatement Do you have a proof? (Show me asm code) Bye, bearophile
Re: Just where has this language gone wrong?
On Mon, 23 Jul 2012 17:19:09 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 23 Jul 2012 22:51:19 +0200 Stuart stu...@gmx.com wrote: On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote: Am 23.07.2012 14:49, schrieb Stuart: On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote: C++ is living in the 70's. Precisely what I have been thinking. It's a loose wrapper around assembly, nothing more. Certainly not the high-level language it's touted as. Only due to the lack of modules. Everything else is a pretty modern language I would say. Hardly. No RTTI. No GC. No properties. No events. No closures. No extension methods. No interfaces. No writable references. Null-terminated strings. Preprocessor. No reflection. Effectively undefined sizes for primitive types. Undefined behavior galore. Neither default initialization nor enforced initialization before variable usage. No reference types (Foo isn't what I mean). Horrendous type syntax for mixed arrays/ptrs or functions ptrs, etc. No forward references (or at least very limited). And a grammar that forces compilation to be very, very slow. Speaking of, I understand he had C++ in mind when he wrote this song: https://www.youtube.com/watch?v=DOj3wDlr_BM
Re: Computed gotos on Reddit
Do you have a proof? (Show me asm code)
Just to be more clear, what I mean is that given a D program
equivalent to the C code shown in the article:
int interp_cgoto(unsigned char* code, int initval) {
static const void* dispatch_table[] = {
do_halt, do_inc, do_dec, do_mul2,
do_div2, do_add7, do_neg};
#define DISPATCH() goto *dispatch_table[code[pc++]]
int pc = 0;
int val = initval;
DISPATCH();
do_halt:
return val;
do_inc:
val++;
DISPATCH();
do_dec:
val--;
DISPATCH();
do_mul2:
val *= 2;
DISPATCH();
do_div2:
val /= 2;
DISPATCH();
do_add7:
val += 7;
DISPATCH();
do_neg:
val = -val;
DISPATCH();
}
int main() {return 0;}
Is a 32 bit D compiler producing asm (with performance) similar
to:
_interp_cgoto:
movl4(%esp), %edx
movzbl (%edx), %eax
addl$1, %edx
movl_dispatch_table.1363(,%eax,4), %ecx
movl8(%esp), %eax
jmp *%ecx
.p2align 4,,7
L3:
rep
ret
.p2align 4,,7
L4:
movzbl (%edx), %ecx
addl$1, %eax
movl_dispatch_table.1363(,%ecx,4), %ecx
.p2align 4,,7
L5:
addl$1, %edx
jmp *%ecx
.p2align 4,,7
L6:
movzbl (%edx), %ecx
subl$1, %eax
movl_dispatch_table.1363(,%ecx,4), %ecx
addl$1, %edx
jmp *%ecx
.p2align 4,,7
L7:
movzbl (%edx), %ecx
addl%eax, %eax
movl_dispatch_table.1363(,%ecx,4), %ecx
addl$1, %edx
jmp *%ecx
.p2align 4,,7
L8:
movl%eax, %ecx
shrl$31, %ecx
addl%ecx, %eax
movzbl (%edx), %ecx
sarl%eax
movl_dispatch_table.1363(,%ecx,4), %ecx
addl$1, %edx
jmp *%ecx
.p2align 4,,7
L9:
movzbl (%edx), %ecx
addl$7, %eax
movl_dispatch_table.1363(,%ecx,4), %ecx
addl$1, %edx
jmp *%ecx
.p2align 4,,7
L10:
movzbl (%edx), %ecx
negl%eax
movl_dispatch_table.1363(,%ecx,4), %ecx
addl$1, %edx
jmp *%ecx
.section .rdata,dr
.align 4
_dispatch_table.1363:
.long L3
.long L4
.long L6
.long L7
.long L8
.long L9
.long L10
Bye,
bearophile
Re: DMD 2.1.0?
On Mon, Jul 23, 2012 at 12:02 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 7/23/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 7/23/12, bearophile bearophileh...@lycos.com wrote: - The many differences between dmd 2.059 and 2.060alpha Is there a changelog somewhere? The DMD changelog seems to be a year old on github. Also I'm getting a JS error on the changelog page: Hyphenator.js says: An Error ocurred: Not enough arguments I fixed that in a pull last night. Looks like Andrei has deployed it. It should be gone now. If not, let Andrei or myself know (and what browser you are using). Regards, Brad Anderson
Re: Computed gotos on Reddit
On 7/23/2012 2:25 PM, bearophile wrote: Walter Bright: D already has it: http://dlang.org/statement.html#FinalSwitchStatement Do you have a proof? (Show me asm code) Since the final switch does not allow a 'default' case, the check can be omitted, and the generated code is a simple index-jump, just like the computed goto example. dmd currently doesn't do that, but that's not the language's fault, it's a quality of implementation issue. The point is, computed goto offers nothing that final switch doesn't.
Re: Computed gotos on Reddit
Walter Bright: dmd currently doesn't do that, but that's not the language's fault, it's a quality of implementation issue. I understand the difference between what compilers are able to do (today or in future), and what the language specs allow compiler writers to do. So in theory I agree. In practice there is also the well known fallacy of the sufficiently smart compiler: http://c2.com/cgi/wiki?SufficientlySmartCompiler This fallacy implies that if you want to actually see a compiler able to perform a certain optimization, such optimization must be rather easy, this means it must be easy for the compiler to infer as true all the conditions necessary to apply that optimization (and then you need someone to actually implement it, in a community as small as the D one optimizations can't be top priority). The other problem with optimizations is that often if you can't rely on them, that means you can't be certain they are used in the code you are writing, then it's like they don't exist. A good example of this is the Scheme standard requiring all Scheme compilers to implement the tail call optimization. Since the final switch does not allow a 'default' case, the check can be omitted, and the generated code is a simple index-jump, just like the computed goto example. You have seen the asm I have shown in the next post. You see those jmp *%ecx at the end of each case. Computed gotos in this case are not just a single index-jump, there is an index-jump at the end of each case. Is your future hypothetical D compiler able to do that? Bye, bearophile
Re: dmd: template.c:5540: Identifier* TemplateInstance::genIdent(Objects*): Assertion `global.errors' failed.
On Monday, 23 July 2012 at 20:54:03 UTC, Nick Sabalausky wrote: On Mon, 23 Jul 2012 22:21:30 +0200 Lukasz wrzo...@gmail.com wrote: I hope someone will put this on bugzilla dmd loops endlessly on this code: import std.typecons; string bug(T..., U : tuple!T)(tuple!T t); dmd aborts on this code: import std.typecons; string bug(T, U : tuple!T)(tuple!T t); enum e = bug(tuple!int); You can put it there: http://d.puremagic.com/issues/ http://d.puremagic.com/issues/show_bug.cgi?id=8421
Re: Optional name mangling
On Monday, 23 July 2012 at 20:57:37 UTC, Stuart wrote: On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote: On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote: Fair enough. But there are still times when we need a version of export that doesn't mangle. No. This is even impossible to do with some compiler backends. For example, LLVM on OS X automatically appends an underscore to the beginning of symbol names, because every C function has an »extra« underscore at the beginning there. I mean for importing. The functions in shlwapi.lib don't have underscores. We ought to have some kind of syntax for importing them without faffing about with .def files. Surely it must be possible? Hi Stuart. If you have the Windows SDK you can run coffimplib C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\shlwapi.lib C:\D\dmd2\windows\lib\shlwapi.lib We could run coffimplib on *.lib from the Windows SDK and include the resulting OMF libraries on the dmd.zip package. I don't know if it is 'legal'.
Re: Computed gotos on Reddit
On 7/23/2012 3:23 PM, bearophile wrote: This fallacy implies that if you want to actually see a compiler able to perform a certain optimization, such optimization must be rather easy, this means it must be easy for the compiler to infer as true all the conditions necessary to apply that optimization (and then you need someone to actually implement it, in a community as small as the D one optimizations can't be top priority). It is easy. Note that the compiler already generates a jump table, this would just leave off the default check. In fact, the compiler could do a better job doing data flow analysis with final switch than computed goto, because the jump targets are constrained and are all known at compile time. BTW, if computed gotos were put into the language, one would also require someone to implement it. You're not saving anything. The other problem with optimizations is that often if you can't rely on them, that means you can't be certain they are used in the code you are writing, then it's like they don't exist. A good example of this is the Scheme standard requiring all Scheme compilers to implement the tail call optimization. Sorry, but I cannot buy this as an argument for loading in more language features. Even worse, requiring that a certain semantic construct be implemented in a certain way precludes the implementer from finding an even better way to do it. You see those jmp *%ecx at the end of each case. Computed gotos in this case are not just a single index-jump, there is an index-jump at the end of each case. Is your future hypothetical D compiler able to do that? Of course. There's no magic technology there. It's just a minor variation on the well known loop rotation technique (which dmd does do). Computed gotos are a rather hackish design that goes around the horn rather than doing what is needed directly.
