Re: gdc-4.5 testing
Lutger Blijdestijn wrote: I uploaded the packages to SourceForge, if anyone else wants to try them... It's made for Fedora 14 (x86_64): Thnx, installs and works fine for a few quick tests. Would be great to see the first D2 compiler in the next fedora release, and debian / ubuntu too of course. Great work! So that would be two different requests, the first is making a new package for D2 and the second is upgrading to GCC 4.6... https://fedoraproject.org/wiki/Features/GCC46 I believe that Ubuntu are sticking with GCC 4.5.x for Natty, or at least 4.5.1 is what is in the current Alpha 1 release ? http://packages.ubuntu.com/natty/gcc The current "dmd" packages have an issue with /usr/bin/dmd and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM, even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't. Any packages for GDC using D2 would have the same problem... But it should be possible to use shims and symlinks to make both installable, at least that's how it works on Mac OS X ? A bigger problem is finding more developers for GCC46 and D2, or perhaps upgrading LDC/Tango to D2 in the case of Fedora ? --anders
Re: gdc-4.5 testing
Anders F Björklund wrote: > Lutger Blijdestijn wrote: >>> I uploaded the packages to SourceForge, if anyone else >>> wants to try them... It's made for Fedora 14 (x86_64): >> >> Thnx, installs and works fine for a few quick tests. Would be great to >> see the first D2 compiler in the next fedora release, and debian / ubuntu >> too of course. Great work! >> > > So that would be two different requests, the first is making > a new package for D2 and the second is upgrading to GCC 4.6... > > https://fedoraproject.org/wiki/Features/GCC46 > > I believe that Ubuntu are sticking with GCC 4.5.x for Natty, > or at least 4.5.1 is what is in the current Alpha 1 release ? > > http://packages.ubuntu.com/natty/gcc > > The current "dmd" packages have an issue with /usr/bin/dmd > and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM, > even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't. > Any packages for GDC using D2 would have the same problem... > > But it should be possible to use shims and symlinks to make > both installable, at least that's how it works on Mac OS X ? > A bigger problem is finding more developers for GCC46 and D2, > or perhaps upgrading LDC/Tango to D2 in the case of Fedora ? > > --anders Yes, it requires some thought and manpower obviously. I'm not a packager, I don't what exactly is proper way to do it, but Fedora already packages python 2.x and python 3.x side by side, so perhaps that is a start. For Fedora I think D2 could be positioned as an alternative to mono in the long run, it fits the distro very well.
Re: Scala containers
Andrei Alexandrescu Wrote: > Still, I wonder how that design compares to D's choice. Runtime polymorphism?
Re: (Improved) Benchmark for Phobos Sort Algorithm
On 18/12/10 4:46 PM, BCS wrote: Hello Craig, It was brought to my attention that the quick sort has a very bad worst case, so I implemented a simple fix for it. Now the worst case (completely ordered) is the best case, and it only slows down the general case by a small percentage. I thought to myself, "it can't be this easy to fix quick sort". Does anyone see a flaw in this simple fix? Performs much better than Phobos in completely random and completely sorted data. Perhaps there is another case where it doesn't do as well? I think I've seen it stated as: If you know the implementation, you can always generate a pathological case for QSort. That's not true for a randomized pivot point (unless you also happen to know the PRNG... and seed).
Re: Game development is worthless? WTF? (Was: Why Ruby?)
On 19/12/10 4:41 PM, Caligo wrote: You are absolutely right; life sucks for many people, and that's why some of them choose to play video games. It gives them a chance to escape reality, and game companies exploit this to make money. Game companies use all kinds of psychology in their games to keep you playing as long as possible. That is why to me there is no honor in game development. Some game developers do that. The vast majority do not. I don't think it's fair to insult developers in general based on the actions of a few. You might as well say there's no honor in software development because some people write viruses and other malware.
DSource.org down?
Here I was going to checkout a fresh version of Derelict2 and DSource.org is down. Any indication of when it'll be up again? Or maybe I can download Derelict2 from somewhere else. Thanks
Re: thin heaps
On 20/12/10 10:01 PM, Andrei Alexandrescu wrote: Just saw this: http://www.reddit.com/r/programming/comments/eoq15/implementing_shortest_path_in_c_is_much_easier/ in which a reader points to this paper on thin heaps: http://www.cs.princeton.edu/courses/archive/spr04/cos423/handouts/thin%20heap.pdf Does anyone here have experience with thin heaps? I think they'd be a good addition to std.container. Andrei I don't know what the constants are, but Soft Heaps apparently have constant time for all operations: http://en.wikipedia.org/wiki/Soft_heap
Should Tuple!( T, "name" ) be implicitly castable to Tuple!T?
I've noticed that (std.typecons') tuples now are assignable to
structurally equal tuples. I'm not sure I agree fully on the choices
made, and figured a discussion might be in order.
1:
Tuple!(int, "a") a;
Tuple!int b;
b = a;
IMO, this is good and correct. A tuple without field names is to me a
mere black box with data inside, and throwing some other data in there
is ok.
2:
Tuple!( int, "a" ) a;
Tuple!int b;
a = b;
This, I am not so sure about. A black box is turned into structured
data. I guess it's ok.
3:
Tuple!( int, "a" ) a;
Tuple!( int, "b" ) b;
a = b;
This I feel, is wrong. a is of a different type from b.
4:
void foo( Tuple!int );
Tuple!(int, "a") a;
foo( a );
This should work. It may be that alias this is not yet good enough to
make this work, but I believe it should be doable by having tuples with
named fields use alias this to turn into tuples without named fields,
and tuples without named fields taking care of []-lookup.
Basically:
struct Tuple(T...) if(containsStrings!T) {
Tuple!(noStrings!T) get() {...}
alias get this;
}
struct Tuple(T...) if(!containsStrings!T) {
T field;
alias field this;
}
--
Simen
Feature: __FUNCTION__ to give name of parent function.
This was a question asked in IRC, someone wanting a way to have the parent function name outputted for logging purposes. Just like there is __LINE__ and __FILE__ for access to the line number and filename, would be handy (and trivial to implement) if there was a __FUNCTION__ variable also for outputting the bare name of the function. Optionally could also add a __PRETTY_FUNCTION__ too for outputting the type signature of the function. ie: writeln(__FUNCTION__); // foo writeln(__PRETTY_FUNCTION__); // int foo(string) Regards
[OT] How to post here without getting spam
I've created this email address (dnewsgro...@yage3d.net) exclusively for posting to this newsgroup, and now it's getting spam. I assume it's from a web-scraper that has harvested the email addresses. Does anyone have any tricks or can anything be done to help this situation?
Re: gdc-4.5 testing
== Quote from Lutger Blijdestijn (lutger.blijdest...@gmail.com)'s article > Anders F Björklund wrote: > > Lutger Blijdestijn wrote: > >>> I uploaded the packages to SourceForge, if anyone else > >>> wants to try them... It's made for Fedora 14 (x86_64): > >> > >> Thnx, installs and works fine for a few quick tests. Would be great to > >> see the first D2 compiler in the next fedora release, and debian / ubuntu > >> too of course. Great work! > >> > > > > So that would be two different requests, the first is making > > a new package for D2 and the second is upgrading to GCC 4.6... > > > > https://fedoraproject.org/wiki/Features/GCC46 > > > > I believe that Ubuntu are sticking with GCC 4.5.x for Natty, > > or at least 4.5.1 is what is in the current Alpha 1 release ? > > > > http://packages.ubuntu.com/natty/gcc > > > > The current "dmd" packages have an issue with /usr/bin/dmd > > and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM, > > even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't. > > Any packages for GDC using D2 would have the same problem... > > > > But it should be possible to use shims and symlinks to make > > both installable, at least that's how it works on Mac OS X ? > > A bigger problem is finding more developers for GCC46 and D2, > > or perhaps upgrading LDC/Tango to D2 in the case of Fedora ? > > > > --anders > Yes, it requires some thought and manpower obviously. I'm not a packager, I > don't what exactly is proper way to do it, but Fedora already packages > python 2.x and python 3.x side by side, so perhaps that is a start. For > Fedora I think D2 could be positioned as an alternative to mono in the long > run, it fits the distro very well. In GCC you have give --program-suffix="foo" to give bespoke program suffixes to the main driver name (gdc). This is usually used to identify different versions of GCC, ie: gdc-4.4, gdc-4.5 Include directories need no altering, as we already install D2 files in /usr/include/d2 Which leaves us with the name of the physical compiler (cc1d). This name is constant for both D1 and D2 at the moment, though it's a one-liner change to rename to "cc1d2" for D2 (see Make-lang.in), and you can have that in your distribution patches. Regards
Re: [OT] How to post here without getting spam
On Tue, 21 Dec 2010 11:33:46 -0500, Eric Poggel wrote: I've created this email address (dnewsgro...@yage3d.net) exclusively for posting to this newsgroup, and now it's getting spam. I assume it's from a web-scraper that has harvested the email addresses. Does anyone have any tricks or can anything be done to help this situation? Use a spam filter? I rarely see spam in my yahoo mail account, and the amount I do get is manageable. Many people don't use a valid email address to avoid spam. There is no requirement to use a valid email address. -Steve
Re: [OT] How to post here without getting spam
Eric Poggel wrote: I've created this email address (dnewsgro...@yage3d.net) exclusively for posting to this newsgroup, and now it's getting spam. I assume it's from a web-scraper that has harvested the email addresses. Does anyone have any tricks or can anything be done to help this situation? What Steve said. Either use a fake or throwaway account, or use a good spam filter. Over 5 years, I've had a grand total of three spam mails get through the gmail filter, and not a single false positive. -- Simen
Re: [OT] How to post here without getting spam
On 12/21/10, Simen kjaeraas wrote: > > What Steve said. Either use a fake or throwaway account, or use a good spam > filter. Over 5 years, I've had a grand total of three spam mails get > through the gmail filter, and not a single false positive. > Yeah, gmail is pretty awesome when it comes to spam filters (YMMV). I still have an old hotmail account which I never use, but I check it once in a while and it's always *loaded* with spam in the inbox.
Re: DSource.org down?
Hi, Yes, I'm also unable to access dsource.org since yesterday. I was looking to get the dstats library. David Simcha, do you have a clone of your lib somewhere else available? Thanks
Re: improvement request - enabling by-value-containers
On 09/12/2010 21:55, Simon Buerger wrote: On 08.12.2010 23:45, Jonathan M Davis wrote: On Wednesday, December 08, 2010 14:14:57 Simon Buerger wrote: For Every lib its a design descision if containers should be value- or reference-types. In C++ STL they are value-types (i.e. the copy-constructor does a real copy), while in tango and phobos the descision was to go for reference-types afaik, but I would like to be able to write value-types too, which isn't possible (in a really good way) currently. Following points would need some love (by-value containers are probably not the only area, where these could be useful) It's extremely rare in my experience that it makes any sense to copy a container on a regular basis. Having an easy means of creating a deep copy of a container or copying the elements from one container to another efficiently would be good, but having containers be value types is almost always a bad idea. It's just not a typical need to need to copy containers - certainly not enough to have them be copied just because you passed them to a function or returned them from one. I think that reference types for containers is very much the correct decision. There should be good ways to copy containers, but copying shouldn't be the default for much of anything in the way of containers. I would go further than that actually, it seems to me that the idea of by-value containers is completely idiotic. I was *hesitant* to say this because it goes against conventional C++ "wisdom" (or rather, C++ mentality), and I'm just a random junior programmer on a web forum, and I am saying it in a somewhat inflammatory way... But frankly, I've been thinking about it for the last few days (the issue came up earlier, in the "Destructors, const structs, and opEquals" thread), and I could not change my mind. For the love of life, how can anyone think this is a good idea? I'm struggling to find even one use-case where it would make sense. (a non-subjective use-case at least) From a pragmatic viewpoint you are right, copying containers is rare. But on the other hand, classes imply a kind of identity, so that a set is a different obejct then an other object with the very same elements. Yeah, classes have identity, but they retain the concept of equality. So what's wrong with that? Equality comparisons would still work the same way as by-value containers. That feels wrong from an aesthetical or mathematical viewpoint. Aesthetics are very subjective (I can say the exact same thing about the opposite case). As for a mathematical viewpoint, yes, it's not exactly the same, but first of all, it's not generally a good idea to strictly emulate mathematical semantics in programming languages. So to speak, mathematical "objects" are immutable, and they exist in a magical infinite space world without the notion of execution or side-effects. Trying to model those semantics in a programming language brings forth a host issues (most of them performance-related). But more important, even if you wanted to do that (to have it right from a mathematical viewpoint), mutable by-value containers are just as bad, you should use immutable data instead. Furthermore, if you have for example a vector of vectors, vector!int row = [1,2,3]; auto vec = Vector!(Vector!int)(5, row); then vec should be 5 rows, and not 5 times the same row. Then instead of "Vector" use a static-length vector type, don't use a container. -- Bruno Medeiros - Software Engineer
Re: [OT] How to post here without getting spam
Steven Schveighoffer wrote: > Many people don't use a valid email address to avoid spam. I doubt that you do know _many_ people and there true behaviour according to email handling. > There is no requirement to use a valid email address. I doubt that you do know _my_ requirements. -manfred
Re: const(Object)ref is here!
On 06/12/2010 19:00, Jonathan M Davis wrote: On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote: On Mon, 06 Dec 2010 04:44:07 -0500, spir wrote: On Mon, 6 Dec 2010 00:31:41 -0800 Jonathan M Davis wrote: toString() (or writeFrom() or whatever it's going to become) guess it was writeTo() ;-) but "writeFrom" is nice as well, we should find some useful use for it It was proposed as writeTo, but I'm not opposed to a different name. I have no problem with writeTo(). I just couldn't remember what it was and didn't want to take the time to look it up, and the name isn't as obvious as toString(), since it's not a standard name which exists in other languages, and it isn't actually returning anything. Whether it's to or from would depend on how you look at it - to the given delegate or from the object. But writeTo() is fine. Once it's used, it'll be remembered. I don't think it's entirely fine. It should at least have "string"/"String" somewhere in the name. (I mentioned this on the other original thread, although late in time) -- Bruno Medeiros - Software Engineer
Re: [OT] How to post here without getting spam
On Tue, 21 Dec 2010 13:12:41 -0500, Manfred_Nowak wrote: Steven Schveighoffer wrote: Many people don't use a valid email address to avoid spam. I doubt that you do know _many_ people and there true behaviour according to email handling. Many = more than a few. There is no requirement to use a valid email address. I doubt that you do know _my_ requirements. I meant the requirement of the server. calm down a bit, I meant no offense. -Steve
Re: custom AST library
I'm just having a look at this now, looks rather interesting! I'd love
to be able to use some Python-like list comprehension tricks in my D
code.
P.S. not sure if it's your fault, but you're code has spaces between
"q" and "{", which gives a compiler error. q{} has to start without
spaces between q and {. ;)
On 11/25/10, Alex_Dovhal wrote:
> Hm... there is some limitations in example code, concerning local variables
> in nested functions... here is workaround http://pastebin.com/mQaKXaYY
>
>
>
Re: custom AST library
SORRY.
Disregard that, it was my fault. My reindenter f*ked it up. You're
code is fine. :)
On 12/21/10, Andrej Mitrovic wrote:
> I'm just having a look at this now, looks rather interesting! I'd love
> to be able to use some Python-like list comprehension tricks in my D
> code.
>
> P.S. not sure if it's your fault, but you're code has spaces between
> "q" and "{", which gives a compiler error. q{} has to start without
> spaces between q and {. ;)
>
> On 11/25/10, Alex_Dovhal wrote:
>> Hm... there is some limitations in example code, concerning local
>> variables
>> in nested functions... here is workaround http://pastebin.com/mQaKXaYY
>>
>>
>>
>
Re: improvement request - enabling by-value-containers
Bruno Medeiros: > For the love of life, how can anyone think this is a > good idea? I'm struggling to find even one use-case where it would make > sense. (a non-subjective use-case at least) I agree that in general collections are better managed by reference. But if you need a hash that you know will not contain more than 10-20 items, and you need max performance, and you don't need to pass it around, than value in-place hash may be useful. I have used it some times. This is not a generic case, but beside the normal collections, Phobos2 may add few little value ones like this. Bye, bearophile
Re: const(Object)ref is here!
On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros wrote: On 06/12/2010 19:00, Jonathan M Davis wrote: On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote: On Mon, 06 Dec 2010 04:44:07 -0500, spir wrote: On Mon, 6 Dec 2010 00:31:41 -0800 Jonathan M Davis wrote: toString() (or writeFrom() or whatever it's going to become) guess it was writeTo() ;-) but "writeFrom" is nice as well, we should find some useful use for it It was proposed as writeTo, but I'm not opposed to a different name. I have no problem with writeTo(). I just couldn't remember what it was and didn't want to take the time to look it up, and the name isn't as obvious as toString(), since it's not a standard name which exists in other languages, and it isn't actually returning anything. Whether it's to or from would depend on how you look at it - to the given delegate or from the object. But writeTo() is fine. Once it's used, it'll be remembered. I don't think it's entirely fine. It should at least have "string"/"String" somewhere in the name. (I mentioned this on the other original thread, although late in time) First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way. writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate. Changing the name to contain 'string' is fine as long as: 1) it's not toString. This is already established as "returning a string" in both prior D and other languages. I think this would be too confusing. 2) it's short. I don't want writeAsStringTo or something similar. What did you have in mind? -Steve
Re: Feature: __FUNCTION__ to give name of parent function.
Iain Buclaw: > someone wanting a way to have the parent function > name outputted for logging purposes. Just like there is __LINE__ and __FILE__ > for > access to the line number and filename, would be handy (and trivial to > implement) > if there was a __FUNCTION__ variable also for outputting the bare name of the > function. I have seen this enhancement request many times. Time ago I have also suggested a reference to the function itself, to be used in self recursive functions. Bye, bearophile
Re: const(Object)ref is here!
Hmm.. if we get uniform function call syntax for all types, perhaps
this code might even work some day:
import std.stdio;
import std.conv;
string toString(A)(A a)
{
return to!string(a);
}
class A
{
string name;
this(string name)
{
this.name = name;
}
string writeTo()
{
return name;
}
}
void main()
{
auto foo = new A("I'm foo! ");
writeln(foo.toString); // using uniform function call syntax
}
Right now this code will compile but it will use Object's toString
instead of the one we defined above.
On 12/21/10, Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros
> wrote:
>
>> On 06/12/2010 19:00, Jonathan M Davis wrote:
>>> On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote:
On Mon, 06 Dec 2010 04:44:07 -0500, spir wrote:
> On Mon, 6 Dec 2010 00:31:41 -0800
>
> Jonathan M Davis wrote:
>> toString() (or writeFrom() or whatever
>> it's going to become)
>
> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should
> find some useful use for it
It was proposed as writeTo, but I'm not opposed to a different name.
>>>
>>> I have no problem with writeTo(). I just couldn't remember what it was
>>> and
>>> didn't want to take the time to look it up, and the name isn't as
>>> obvious as
>>> toString(), since it's not a standard name which exists in other
>>> languages, and
>>> it isn't actually returning anything. Whether it's to or from would
>>> depend on
>>> how you look at it - to the given delegate or from the object. But
>>> writeTo() is
>>> fine. Once it's used, it'll be remembered.
>>>
>>
>> I don't think it's entirely fine. It should at least have
>> "string"/"String" somewhere in the name. (I mentioned this on the other
>> original thread, although late in time)
>
> First, I'll say that it's not as important to me as it seems to be to you,
> and I think others feel the same way. writeTo seems perfectly fine to me,
> and the 'string' part is implied by the char[] parameter for the delegate.
>
> Changing the name to contain 'string' is fine as long as:
>
> 1) it's not toString. This is already established as "returning a string"
> in both prior D and other languages. I think this would be too confusing.
> 2) it's short. I don't want writeAsStringTo or something similar.
>
> What did you have in mind?
>
> -Steve
>
Re: Destructors, const structs, and opEquals
On 10/12/2010 20:58, Andrei Alexandrescu wrote: On 12/10/10 12:46 PM, Steven Schveighoffer wrote: On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer wrote: On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu wrote: Sorry, indeed I haven't seen it. The problem with binding rvalues to const ref is that once that is in place you have no way to distinguish an rvalue from a const ref on the callee site. If you do want to distinguish, you must rely on complicated conversion priorities. For example, consider: void foo(ref const Widget); void foo(Widget); You'd sometimes want to do that because you want to exploit an rvalue by e.g. moving its state instead of copying it. However, if rvalues become convertible to ref const, then they are motivated to go either way. A rule could be put in place that gives priority to the second declaration. However, things quickly get complicated in the presence of other applicable rules, multiple parameters etc. Essentially it was impossible for C++ to go this way and that's how rvalue references were born. For D I want to avoid all that aggravation and have a simple rule: rvalues don't bind to references to const. If you don't care, use auto ref. This is a simple rule that works promisingly well in various forwarding scenarios. Andrei For some cases, one could just use a differently-named function, instead of overloading it (like 'foo'). That wouldn't solve the issue for generic code (or operator overloading), yes. But I wonder if this is common and important enough (versus the alternative) to merit a new type qualifier or "storage class". If this is really necessary, I think it might be better to have rvalues convertible to ref const, and instead of "auto ref" have a new qualifier that binds *only* to rvalues, like ref(auto) or ref(in) or whatever. This way the more common case is simpler (just "const Widget" instead of "auto ref const Widget", in the case of opEquals for example). And as for distinguishing rvalues, the example above would be: void foo(ref(in) Widget); // exploit rvalue, move state void foo(Widget); which also has the advantage of being able to distinguish the rvalue without making the whole parameter const (which is unnecessarily transitive, unlike C++) -- Bruno Medeiros - Software Engineer
Re: Destructors, const structs, and opEquals
On 10/12/2010 21:17, Andrei Alexandrescu wrote: We all need to think about this a bit more because it's related to another issue that I'm still losing sleep over: should we promote cheap copy construction throughout D or not? I was reminded of another comment that could be said in favor of that: If you look back at your own article and thoughts about ranges and iteration, you made the case for the benefits of the iteration primitives having complexity guarantees (just as is the case with STL). It seems to me that the very same reasoning could be applied to these fundamental type primitives, like the copy constructor at least. If the copy constructor guarantees constant complexity, then other algorithms and operations can be built on top of that, and also provide useful complexity guarantees. Like the sort example you mentioned. (Hum, and if we go this way, it will probably be best not to call it "copy constructor" then) -- Bruno Medeiros - Software Engineer
Re: const(Object)ref is here!
On Tue, 21 Dec 2010 19:46:11 +0100, Andrej Mitrovic
wrote:
Hmm.. if we get uniform function call syntax for all types, perhaps
this code might even work some day:
import std.stdio;
import std.conv;
string toString(A)(A a)
{
return to!string(a);
}
class A
{
string name;
this(string name)
{
this.name = name;
}
string writeTo()
{
return name;
}
}
void main()
{
auto foo = new A("I'm foo! ");
writeln(foo.toString); // using uniform function call syntax
}
Right now this code will compile but it will use Object's toString
instead of the one we defined above.
It would still use Object's toString, as member functions would be
tested for first.
--
Simen
Re: const(Object)ref is here!
On 12/21/10, Simen kjaeraas wrote: > It would still use Object's toString, as member functions would be > tested for first. > > -- > Simen > I'm talking about the case where Object's toString function doesn't exist (in some future release of D), but is replaced with writeTo or some alternate name. In that case your old code could still compile by adding this toString template.
Re: const(Object)ref is here!
On 12/21/10 12:19 PM, Steven Schveighoffer wrote: On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros wrote: On 06/12/2010 19:00, Jonathan M Davis wrote: On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote: On Mon, 06 Dec 2010 04:44:07 -0500, spir wrote: On Mon, 6 Dec 2010 00:31:41 -0800 Jonathan M Davis wrote: toString() (or writeFrom() or whatever it's going to become) guess it was writeTo() ;-) but "writeFrom" is nice as well, we should find some useful use for it It was proposed as writeTo, but I'm not opposed to a different name. I have no problem with writeTo(). I just couldn't remember what it was and didn't want to take the time to look it up, and the name isn't as obvious as toString(), since it's not a standard name which exists in other languages, and it isn't actually returning anything. Whether it's to or from would depend on how you look at it - to the given delegate or from the object. But writeTo() is fine. Once it's used, it'll be remembered. I don't think it's entirely fine. It should at least have "string"/"String" somewhere in the name. (I mentioned this on the other original thread, although late in time) First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way. writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate. Changing the name to contain 'string' is fine as long as: 1) it's not toString. This is already established as "returning a string" in both prior D and other languages. I think this would be too confusing. 2) it's short. I don't want writeAsStringTo or something similar. What did you have in mind? -Steve Conversion to text should be called toText. That makes the essence of the function visible (it emits characters) without tying the representation of the text. Andrei
Re: Feature: __FUNCTION__ to give name of parent function.
On 12/21/10 10:20 AM, Iain Buclaw wrote: This was a question asked in IRC, someone wanting a way to have the parent function name outputted for logging purposes. Just like there is __LINE__ and __FILE__ for access to the line number and filename, would be handy (and trivial to implement) if there was a __FUNCTION__ variable also for outputting the bare name of the function. Optionally could also add a __PRETTY_FUNCTION__ too for outputting the type signature of the function. ie: writeln(__FUNCTION__); // foo writeln(__PRETTY_FUNCTION__); // int foo(string) Regards Yah, we need such. To help with generic code, I'm hoping for: function.stringof module.stringof class.stringof struct.stringof union.stringof enum.stringof to yield the name of the current entity. Andrei
Re: New syntax for string mixins
"Don" wrote:
> In order for CTFE code to call pre-compiled code, three things are
> required:
> (1) the compiler needs to be able to find the file (.obj/.lib/shared
> library) containing the compiled code;
> (2) the compiler needs to be able to load the module and call it. This
> requires some form of dynamic linking.
> (3) We need a marshalling step, to convert from compiler literal to
> compiled data, and back.
>
>
> Step (3) is straightforward. The challenge is step(2), although note that
> it's a general "allow the compiler to load a plugin" problem, and doesn't
> have much to do with CTFE.
I thought it over, and got:
(1) can be solved by adding compiler option: --macro-libs=, so
the compiler knows in which dynamic libraries to search for the plugins ;
(2) plugin library functions should be *stdcall*, so C++ compiler can load
them. That library should implement function like that:
PluginInfo* getFunctionsInfo () ;
where:
typedef struct _PluginInfo{
struct _PluginInfo * nextPlugin ;
char* fcnName ; // short name of a function, e.g. "fcn"
char* params ; // param list, e.g. "(int, float, char*)"
char* mangledName;//name of funct. in the library, e.g. "_...@12"
char* returnType ; // e.g. "int"
bool isNothrow ; // if useful?
bool isPure ;// ditto
//... etc ...
} PluginInfo ;
And also should implement all the functions, info about which is returned by
getFunctionsInfo().
D compiler calls getFunctionsInfo from each plugin library - and then loads
all the implemented functions with full info about them.
If one plugin function name found in two or more libraries - D throws
compiler error.
Not a perfect solution, but at least straightforward one and solves given
problem.
One more note: this approach makes CTFE functions calling such plugins
uncallable at runtime, which IMO is OK, as one should not call it in any
case.
Is that suitable?
Re: [OT] How to post here without getting spam
Steven Schveighoffer wrote: > no offense no offense too, only doubts. -manfred
Re: Feature: __FUNCTION__ to give name of parent function.
On Tuesday, December 21, 2010 08:20:06 Iain Buclaw wrote: > This was a question asked in IRC, someone wanting a way to have the parent > function name outputted for logging purposes. Just like there is __LINE__ > and __FILE__ for access to the line number and filename, would be handy > (and trivial to implement) if there was a __FUNCTION__ variable also for > outputting the bare name of the function. Optionally could also add a > __PRETTY_FUNCTION__ too for outputting the type signature of the function. > > ie: > writeln(__FUNCTION__); // foo > writeln(__PRETTY_FUNCTION__); // int foo(string) > > Regards __FUNCTION__ exists in C++. I added a feature request for it a couple of months ago: http://d.puremagic.com/issues/show_bug.cgi?id=5140
Azul's Pauseless GC
http://www.artima.com/lejava/articles/azul_pauseless_gc.html Interesting read. Not usable on current OS's, sadly. -- Simen
Re: Azul's Pauseless GC
Simen kjaeraas wrote: http://www.artima.com/lejava/articles/azul_pauseless_gc.html Interesting read. Not usable on current OS's, sadly. Oh, and the reason I posted this: Given the OS support outlined in the article, would this be possible for D too? -- Simen
Re: [OT] How to post here without getting spam
On 12/21/2010 11:46 AM, Simen kjaeraas wrote: Eric Poggel wrote: I've created this email address (dnewsgro...@yage3d.net) exclusively for posting to this newsgroup, and now it's getting spam. I assume it's from a web-scraper that has harvested the email addresses. Does anyone have any tricks or can anything be done to help this situation? What Steve said. Either use a fake or throwaway account, or use a good spam filter. Over 5 years, I've had a grand total of three spam mails get through the gmail filter, and not a single false positive. I get several spams from my gmail account every week.
Re: Why Ruby?
On 11/12/2010 01:26, Ary Borenszweig wrote: http://vimeo.com/17420638 A very interesting talk. Whoa. Over the last 5 years or so, with surge in popularity of dynamic languages like Ruby, Python, etc., I've seen several arguments put forth in favor of dynamic typing, and gradually I've always found there was a /subtle/ parallel with the arguments and reasons put forth for libertarian/anti-authoritarian/anti-corporate ideologies. After seeing this talk, I guess it's not so subtle after all... ~_~' Let me offer my thoughts on this. I don't think his argument is fundamentally rational. And I don't just mean wrong or illogical, I mean /irrational/: it is driven by an emotional bias of something not related to programmer productivity, which is what the discussion should be about. And I think his opinion is somewhat generally representative of many dynamic language proponents. What I think is happening is this: These people, if and when they program on languages with static typing, they get annoyed by some (or all) of the aspects of static typing. That's normal so far, but now the problem is that while some of this annoyance may be driven from a genuine questioning of whether static typing is worth it or not (in usefulness and productivity), the rest of the annoyance is instead driven by an external emotional factor: if the language doesn't let you do something that it could easily let you do, then it is perceived as a "restriction of your freedoms". The programmer makes an emotional connection to personal issues unrelated to the field of programming. Another variant of this emotional response in this situation, and probably a much more common one, is not about political ideology, but rather the programmer perceives the language restriction to be part of a corporate culture that says that programmers are not smart enough to be fully trusted, and they need to be controlled to make sure they don't do stupid things. In other words the language thinks your are a dumb monkey who needs to be kept in line. Java is the poster child for this mentality, not only due to the language itself which is perceived to be simplistic, but also due to Java's strong association to the corporate and enterprise world. In a less extreme view, it is not about controlling stupidity, but controlling creativity (a view popular amongst "artist"/"painter" programmers). So here the programmers are not dumb, but still they need to be kept in line with rules, constraints, specifications, strict APIs, etc.. You can't do anything too strange or out of the ordinary, and the language is a reflection of that, especially with regards to restrictions on dynamic typing (and other dynamic stuff like runtime class modification). Unfortunately this emotional response is often not fully conscious, or at least, it is not clearly expressed to others by the underlying programmer. And once this happens, _everything is lost from the beginning, in terms of trying to have a sensible debate._ Because from now on, these programmers will use half-baked arguments to try to justify their preference of dynamic languages. The arguments will be half-baked because they will try to argue in the area of effectiveness (programmer productivity), yet the main reason they like/dislike the language is the attitude of the language creators and/or community. (Interestingly enough, an incredibly similar cognitive-dissonance driven fallacy happens in discussions of actual political ideologies) (Note, I'm not saying this is the case with all programmers, or even most, of the proponents of dynamic typing. In particular, nor I am saying it's the case with Ary :p ) BTW, for a while I was quite okay with this talk, because the author seemed to make clear what the liked about Ruby was the underlying attitude. He mentioned the language design goal of "making the programmer happy". He mentioned all those quirks of the community like the 'second' property, the 42 one, the cheerleaders at the convention, etc.. But then he made those comments about how static typing is there in Java and other languages because it is thought programmers are too stupid to be able to handle things otherwise (don't remember his exact words), or even worse, the comment/point about how many programmers in the audience made a bug because of not specifying a type... And from that point it was easy to go downhill, and indeed the talk did. Although I am happy for him making that explicit parallel with political ideology, it illustrates my point very well, even if not all Ruby developers would agree with him 100%. Note that all of what I said above is a comment about the nature of the discussion of static vs. typing. I didn't make an actual argument for or against static typing (in case you were thinking this was the intention). I won't do that now, I'll just say that, not only I am a long-time proponent of static typing, in the last few
Re: Why Ruby?
On 18/12/2010 05:54, Caligo wrote: IMO there is no honor in game development as it contributes nothing to society. You don't think entertainment contributes to society? -- Bruno Medeiros - Software Engineer
Re: [OT] How to post here without getting spam
"Eric Poggel" wrote in message news:ieql0o$30a...@digitalmars.com... > I've created this email address (dnewsgro...@yage3d.net) exclusively for > posting to this newsgroup, and now it's getting spam. I assume it's from > a web-scraper that has harvested the email addresses. Does anyone have > any tricks or can anything be done to help this situation? There's a ton of NG-viewing webpages out there and all is takes is for one of them to decide to (or accidentally) show email addresses, or for one spambot developer to decide to scan NGs directly. That's why I've always just used a...@a.a on the NG. Someone wants to email me, no prob, they can ask on the NG, and I'll provide a sanitized version. I never use spam filters because I've don't trust them - I've never found one (including gmail) that didn't give me an unacceptable amount of both false positives and false negatives. (And I know I get really annoyed when legitimate messages I send get blocked by overzealous filters.)
Re: Game development is worthless? WTF? (Was: Why Ruby?)
On 19/12/2010 14:21, Ary Borenszweig wrote: Seeing the enemy being literally eaten by hundreds of upgraded zerglings has no comparison. :-) I'm more of a Protoss guy myself... Reaver drop FTW! (I'll need to re-evaluate things with Starcraft II) BTW, its funny to try to make some parallels between the races and languages: Protoss == Java. Very powerful, teleports ready made structures from other dimensions (= all the libraries, middleware, app stack that is readily available). But still needs some setup (pylons). And very expensive in resources (slow), and very dependent on energy (GC-activity / having enough free memory). Humans == C++: also quite powerful, but dirty, smelly, crude, oily, smoke filled, patchy. Breaks often and needs constant repairs (SCV repairs, otherwise blows up in flames). Non elegant. Can mount a good defense/offense anywhere on the map (siege tanks, bunker forward build attacks). But not as agile. Ruby == Zerg. Utter chaos. Units can evolve into other units (dynamic typing). Very good for rushes and early game attacks (= rapid application deploying, kekekeke Rails Rush, gg). Very fast, very agile (=agile). Nydus Canals = Monkey Patching (likes to break abstractions). -- Bruno Medeiros - Software Engineer
Re: Feature: __FUNCTION__ to give name of parent function.
"Andrei Alexandrescu" wrote in message news:iequlo$rd...@digitalmars.com... > On 12/21/10 10:20 AM, Iain Buclaw wrote: >> This was a question asked in IRC, someone wanting a way to have the >> parent function >> name outputted for logging purposes. Just like there is __LINE__ and >> __FILE__ for >> access to the line number and filename, would be handy (and trivial to >> implement) >> if there was a __FUNCTION__ variable also for outputting the bare name of >> the >> function. Optionally could also add a __PRETTY_FUNCTION__ too for >> outputting the >> type signature of the function. >> >> ie: >> writeln(__FUNCTION__); // foo >> writeln(__PRETTY_FUNCTION__); // int foo(string) >> >> Regards > > Yah, we need such. To help with generic code, I'm hoping for: > > function.stringof > module.stringof > class.stringof > struct.stringof > union.stringof > enum.stringof > > to yield the name of the current entity. > Yea, I don't even care what the syntax for it is; it's such a frequent request, there should at least be some way to invoke it.
Re: Why Ruby?
On 13/12/2010 20:25, Paolo Invernizzi wrote: Also with bugs (the most hated is the *freeze* one), I'm still using Descent every single day, to code in D in the company where I work. By far it is the most productive and incredible D IDE (sorry Bruno, I *relly* hope that DDT will catch up!). I'm hoping for that as well! -- Bruno Medeiros - Software Engineer
Re: DSource.org down?
"somebody" wrote in message news:ieqeih$2li...@digitalmars.com... > Here I was going to checkout a fresh version of Derelict2 and > DSource.org is down. > > Any indication of when it'll be up again? Or maybe I can download > Derelict2 from somewhere else. > It does tend to go down periodically. Always comes back though.
[OT] Re: Offense programming
"bearophile" wrote in message news:ielcv6$1n9...@digitalmars.com... > This author shows a bit of exasperation caused by the current crop of > programming languages. No popular language around today seems fit for high > integrity systems. I think with some changes, improvements and > restrictions D may become fit for this small but important niche: > > http://blog.kickin-the-darkness.com/2010/12/defensive-programming-fortran-ada-c.html > Now *this* is "offensive programming": ;) http://www.semiologic.com/2005/04/27/fuckfuck/
Re: Why Ruby?
On 11/12/2010 13:53, Ary Borenszweig wrote: I guess what I liked about it (and Ruby) is that I see everything is very consistent and nice to my eyes. I never squeeze my brian to understand a piece of code, nor I had to deal with __some__strange variable names, or even __keywords. Code is read many more times than it is written and so it is of huge important that code is as readable as possible. Of course this is a subjective matter, but I don't understand why some people think __traits or __gshared are ok. So what if those are compiler extensions or whatever? I don't want to stop thinking about those details of a programming language when I'm dealing with another problem. When I read Ruby code I feel like I'm reading an English textbook (better, a poem :-P), while why I read other languages I feel I'm reading... well, a programming language. And my head is so much better at reading text than reading machine code. Then, other things in D like properties for which you do ++ don't work or such corner cases doesn't happen in Ruby. It's consistent. Once Ruby defines something, it does it well, not just half through it. I see what with mean with consistency, and I agree with that. Especially in regards to criticism of D, yeah, there is a lot of stuff I think that could be simplified, removed, made consistent, cleaned, generalized, etc.. But I would never trade those downsides for a language with dynamic typing, not even close! And this regardless of whether the language is systems programmings (like D), or not (like Java). -- Bruno Medeiros - Software Engineer
Re: custom AST library
"Andrej Mitrovic" wrote:
> I'm just having a look at this now, looks rather interesting! I'd love
> to be able to use some Python-like list comprehension tricks in my D
> code.
Yes list comprehension is also possible this way. But it is not very eye
handy right now even if fully implemented, because one can't use variables
external to the scope of sum or listcomp... templates, also those
parenthesis and braces..., so must write:
float a = 1 ;
int n = 10 ;
float x = mixin(sumImpl(q{i=0:10; a*i})) ;
float y = mixin(sumImpl(q{i=1:n; i*mixin(prodImpl(q{j=0:i ; i+j}))}));
instead of:
float a = 1 ;
int n = 10 ;
float x = sum!(q{i=0:10; a*i}) ;
float y = sum!(q{i=1:n; i*prod!(q{j=0:i ; i+j})});
I made it as my first attempt to use D, that's why maybe it's not solid or
well designed, so any ideas are welcomed.
Re: gdc-4.5 testing
Anders F Björklund wrote: > Neal Becker wrote: >> Does this support building shared libs now (on x86_64)? >> > ... >>> I uploaded the packages to SourceForge, if anyone else >>> wants to try them... It's made for Fedora 14 (x86_64): >>> >>> http://sourceforge.net/projects/gdcgnu/files/gdc/8ac6cb4f40aa/ > > You mean in general, or specifics ? (like throwing exceptions > or allocating memory or whatever...) Was it a problem before ? > > Basic creation seems to work: > > $ gdc -fPIC -o foo.o -c foo.d > $ gcc -shared -o libfoo.so foo.o > $ file libfoo.so > libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), > dynamically linked, not stripped > > AFAIK both shared libraries and x86_64 code have been working > for years with GDC, even though that is not the case with DMD. > > Phobos is still static, though. > > --anders But you can't link shared obj to static lib (Phobos), except on i386 - so you really can't use shared obj on x86_64 (if you need phobos).
Re: Why Ruby?
On 13/12/2010 15:49, Andrei Alexandrescu wrote:
On 12/13/10 9:11 AM, Jeff Nowakowski wrote:
On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
Yes I am :-)
Since you were the Descent author, I wonder how you feel about Ruby's
lack of static typing. In the video, the speaker bashes type safety as
"having your balls fondled at the airport", that is, security theater
that doesn't accomplish much.
By the way, I couldn't stop cringing at the distasteful, male-centric
sexual jokes that the talk is peppered with. Wonder if there was any
woman in the audience, and how she might have felt. And this is not a
ghetto rant - it's the keynote of a major Ruby conference! (And I'm
definitely not a prude.) Am I alone in thinking that this is not what
our metier should evolve into?
Besides, the argument in favor of dynamic typing is one of the most
disingenuous around. C is a language for consenting adults that gives
you that kind of freedom. If we took the speaker's arguments to their
logical conclusion, Ruby would be a language for people who don't care
about correctness, despise efficiency, and have contempt for modularity.
Ah, hold on a second. I agree the talk was rude and unprofessional (not
that it was meant to be either), but I disagree it was sexist or
offensive to women. Looking at the comment in question, "having your
balls fondled at the airport", it's simply something that you cannot
convey with anywhere the same meaning in a gender-neutral way ("having
your gonads fondled at the airports"?... "having your genitals fondled
at the airport"?... "having your crotch fondled at the airport"?...)
For better or worse, "balls" has become a metaphor for braveness,
boldness, power, recklessness, (or a combination therefore), and has
even been applied to women some times ("does she have the balls to do
that?").
--
Bruno Medeiros - Software Engineer
Re: Why Ruby?
"Bruno Medeiros" wrote in message news:ier0hh$us...@digitalmars.com... > On 11/12/2010 01:26, Ary Borenszweig wrote: >> http://vimeo.com/17420638 >> >> A very interesting talk. >> > > Whoa. > > Over the last 5 years or so, with surge in popularity of dynamic languages > like Ruby, Python, etc., I've seen several arguments put forth in favor of > dynamic typing, and gradually I've always found there was a /subtle/ > parallel with the arguments and reasons put forth for > libertarian/anti-authoritarian/anti-corporate ideologies. > After seeing this talk, I guess it's not so subtle after all... ~_~' > > > Let me offer my thoughts on this. I don't think his argument is > fundamentally rational. And I don't just mean wrong or illogical, I mean > /irrational/: it is driven by an emotional bias of something not related > to programmer productivity, which is what the discussion should be about. > And I think his opinion is somewhat generally representative of many > dynamic language proponents. > > What I think is happening is this: These people, if and when they program > on languages with static typing, they get annoyed by some (or all) of the > aspects of static typing. That's normal so far, but now the problem is > that while some of this annoyance may be driven from a genuine questioning > of whether static typing is worth it or not (in usefulness and > productivity), the rest of the annoyance is instead driven by an external > emotional factor: if the language doesn't let you do something that it > could easily let you do, then it is perceived as a "restriction of your > freedoms". The programmer makes an emotional connection to personal issues > unrelated to the field of programming. Another variant of this emotional > response in this situation, and probably a much more common one, is not > about political ideology, but rather the programmer perceives the language > restriction to be part of a corporate culture that says that programmers > are not smart enough to be fully trusted, and they need to be controlled > to make sure they don't do stupid things. In other words the language > thinks your are a dumb monkey who needs to be kept in line. Java is the > poster child for this mentality, not only due to the language itself which > is perceived to be simplistic, but also due to Java's strong association > to the corporate and enterprise world. In a less extreme view, it is not > about controlling stupidity, but controlling creativity (a view popular > amongst "artist"/"painter" programmers). So here the programmers are not > dumb, but still they need to be kept in line with rules, constraints, > specifications, strict APIs, etc.. You can't do anything too strange or > out of the ordinary, and the language is a reflection of that, especially > with regards to restrictions on dynamic typing (and other dynamic stuff > like runtime class modification). > > Unfortunately this emotional response is often not fully conscious, or at > least, it is not clearly expressed to others by the underlying programmer. > And once this happens, _everything is lost from the beginning, in terms of > trying to have a sensible debate._ Because from now on, these programmers > will use half-baked arguments to try to justify their preference of > dynamic languages. The arguments will be half-baked because they will try > to argue in the area of effectiveness (programmer productivity), yet the > main reason they like/dislike the language is the attitude of the language > creators and/or community. (Interestingly enough, an incredibly similar > cognitive-dissonance driven fallacy happens in discussions of actual > political ideologies) > > (Note, I'm not saying this is the case with all programmers, or even most, > of the proponents of dynamic typing. In particular, nor I am saying it's > the case with Ary :p ) > > > BTW, for a while I was quite okay with this talk, because the author > seemed to make clear what the liked about Ruby was the underlying > attitude. He mentioned the language design goal of "making the programmer > happy". He mentioned all those quirks of the community like the 'second' > property, the 42 one, the cheerleaders at the convention, etc.. But then > he made those comments about how static typing is there in Java and other > languages because it is thought programmers are too stupid to be able to > handle things otherwise (don't remember his exact words), or even worse, > the comment/point about how many programmers in the audience made a bug > because of not specifying a type... And from that point it was easy to go > downhill, and indeed the talk did. Although I am happy for him making that > explicit parallel with political ideology, it illustrates my point very > well, even if not all Ruby developers would agree with him 100%. > > > Note that all of what I said above is a comment about the nature of the > discussion of static vs. typing. I didn'
Re: Why Ruby?
On Tue, 21 Dec 2010 14:50:21 -0500, Bruno Medeiros wrote: In a less extreme view, it is not about controlling stupidity, but controlling creativity (a view popular amongst "artist"/"painter" programmers). So here the programmers are not dumb, but still they need to be kept in line with rules, constraints, specifications, strict APIs, etc.. You can't do anything too strange or out of the ordinary, and the language is a reflection of that, especially with regards to restrictions on dynamic typing (and other dynamic stuff like runtime class modification). Those aren't bugs, they are the artistic qualities of my program! It's a statement on the political bias against bugs, I mean most people kill bugs without a second thought! ;) -Steve
Re: custom AST library
That's why I think it might be a better idea to simply use "DSL
blocks" throughout your code. Instead of having to mixin each
template, you would only have one template where you have all the
rules for your DSL:
float a = 1 ;
int n = 10 ;
// more D code..
mixin(MyDSL!(q{
// Here you use the syntax defined by the "MyDSL" language
float x = sum!(i=0:10; a*i) ;
float y = sum!(i=1:n; i*prod!(j=0:i ; i+j);
// More MyDSL code..
}));
// Here you use D syntax again, and D will know about float x and float y.
Not to mention that you could potentially have some control over
syntax highlighting (if you have a capable editor :p). For example you
could write a little script in VIM which detects the use of "MyDSL!()"
template, and highlights the code inside the block differently than
the one outside the block.
On 12/21/10, Alex_Dovhal wrote:
> "Andrej Mitrovic" wrote:
>> I'm just having a look at this now, looks rather interesting! I'd love
>> to be able to use some Python-like list comprehension tricks in my D
>> code.
>
> Yes list comprehension is also possible this way. But it is not very eye
> handy right now even if fully implemented, because one can't use variables
> external to the scope of sum or listcomp... templates, also those
> parenthesis and braces..., so must write:
>
> float a = 1 ;
> int n = 10 ;
> float x = mixin(sumImpl(q{i=0:10; a*i})) ;
> float y = mixin(sumImpl(q{i=1:n; i*mixin(prodImpl(q{j=0:i ; i+j}))}));
>
> instead of:
>
> float a = 1 ;
> int n = 10 ;
> float x = sum!(q{i=0:10; a*i}) ;
> float y = sum!(q{i=1:n; i*prod!(q{j=0:i ; i+j})});
>
> I made it as my first attempt to use D, that's why maybe it's not solid or
> well designed, so any ideas are welcomed.
>
>
>
synchronized statements in C++ ;)
http://rastergrid.com/blog/2010/02/synchronizable-objects-for-c/ C++ is still desperately trying ;)
Re: Why Ruby?
Tue, 21 Dec 2010 19:50:21 +, Bruno Medeiros wrote: > On 11/12/2010 01:26, Ary Borenszweig wrote: >> http://vimeo.com/17420638 >> >> A very interesting talk. >> >> > Whoa. > > Over the last 5 years or so, with surge in popularity of dynamic > languages like Ruby, Python, etc., I've seen several arguments put forth > in favor of dynamic typing, and gradually I've always found there was a > /subtle/ parallel with the arguments and reasons put forth for > libertarian/anti-authoritarian/anti-corporate ideologies. After seeing > this talk, I guess it's not so subtle after all... ~_~' > > > Let me offer my thoughts on this. I don't think his argument is > fundamentally rational. And I don't just mean wrong or illogical, I mean > /irrational/: it is driven by an emotional bias of something not related > to programmer productivity, which is what the discussion should be > about. And I think his opinion is somewhat generally representative of > many dynamic language proponents. > > What I think is happening is this: These people, if and when they > program on languages with static typing, they get annoyed by some (or > all) of the aspects of static typing. That's normal so far, but now the > problem is that while some of this annoyance may be driven from a > genuine questioning of whether static typing is worth it or not (in > usefulness and productivity), the rest of the annoyance is instead > driven by an external emotional factor: if the language doesn't let you > do something that it could easily let you do, then it is perceived as a > "restriction of your freedoms". The programmer makes an emotional > connection to personal issues unrelated to the field of programming. > Another variant of this emotional response in this situation, and > probably a much more common one, is not about political ideology, but > rather the programmer perceives the language restriction to be part of a > corporate culture that says that programmers are not smart enough to be > fully trusted, and they need to be controlled to make sure they don't do > stupid things. In other words the language thinks your are a dumb monkey > who needs to be kept in line. Java is the poster child for this > mentality, not only due to the language itself which is perceived to be > simplistic, but also due to Java's strong association to the corporate > and enterprise world. In a less extreme view, it is not about > controlling stupidity, but controlling creativity (a view popular > amongst "artist"/"painter" programmers). So here the programmers are not > dumb, but still they need to be kept in line with rules, constraints, > specifications, strict APIs, etc.. You can't do anything too strange or > out of the ordinary, and the language is a reflection of that, > especially with regards to restrictions on dynamic typing (and other > dynamic stuff like runtime class modification). > > Unfortunately this emotional response is often not fully conscious, or > at least, it is not clearly expressed to others by the underlying > programmer. And once this happens, _everything is lost from the > beginning, in terms of trying to have a sensible debate._ Because from > now on, these programmers will use half-baked arguments to try to > justify their preference of dynamic languages. The arguments will be > half-baked because they will try to argue in the area of effectiveness > (programmer productivity), yet the main reason they like/dislike the > language is the attitude of the language creators and/or community. > (Interestingly enough, an incredibly similar cognitive-dissonance driven > fallacy happens in discussions of actual political ideologies) > > (Note, I'm not saying this is the case with all programmers, or even > most, of the proponents of dynamic typing. In particular, nor I am > saying it's the case with Ary :p ) > > > BTW, for a while I was quite okay with this talk, because the author > seemed to make clear what the liked about Ruby was the underlying > attitude. He mentioned the language design goal of "making the > programmer happy". He mentioned all those quirks of the community like > the 'second' property, the 42 one, the cheerleaders at the convention, > etc.. But then he made those comments about how static typing is there > in Java and other languages because it is thought programmers are too > stupid to be able to handle things otherwise (don't remember his exact > words), or even worse, the comment/point about how many programmers in > the audience made a bug because of not specifying a type... And from > that point it was easy to go downhill, and indeed the talk did. Although > I am happy for him making that explicit parallel with political > ideology, it illustrates my point very well, even if not all Ruby > developers would agree with him 100%. > > > Note that all of what I said above is a comment about the nature of the > discussion of static vs. typing. I didn't make an actual argument for or > against static typing (in
Re: gdc-4.5 testing
Lutger Blijdestijn wrote: But it should be possible to use shims and symlinks to make both installable, at least that's how it works on Mac OS X ? A bigger problem is finding more developers for GCC46 and D2, or perhaps upgrading LDC/Tango to D2 in the case of Fedora ? Yes, it requires some thought and manpower obviously. I'm not a packager, I don't what exactly is proper way to do it, but Fedora already packages python 2.x and python 3.x side by side, so perhaps that is a start. Well, that uses "python3" so by extension it would be using "d2" ? It would also need some better way for packaging D programs than the current "BuildRequires: ldc". And portable $DFLAGS, e.g. -frelease In https://fedoraproject.org/wiki/D+packaging+guideline+draft But I don't know... It is soon 4 years since it (D) was originally released and packaged for inclusion in Fedora (Core at the time) ? It's always possible to install GDC or DMD manually, even if it is not supported by your distribution. It just takes a bigger effort. But it isn't _that_ much harder packaging GCC/GDC than DMC/DMD... Even if it would be preferable to use the system gcc, if possible. You *should* take it up with Fedora, if you want GDC to be included. For Fedora I think D2 could be positioned as an alternative to mono in the long run, it fits the distro very well. I thought that Vala was already positioned as the alternative to Mono ? At least when it came to writing GTK+ (and other GObject) applications. But yeah, I was originally hoping on using D as an alternative to Java. --anders
Re: gdc-4.5 testing
Neal Becker wrote: AFAIK both shared libraries and x86_64 code have been working for years with GDC, even though that is not the case with DMD. Phobos is still static, though. But you can't link shared obj to static lib (Phobos), except on i386 - so you really can't use shared obj on x86_64 (if you need phobos). I don't get it, it shouldn't be that much different from a static libstdc++ or something. You do need libgcc_s.so for the exceptions to be thrown correctly, but otherwise your application would be linking to Phobos anyway I thought... Do you have some more advanced example than the toy tests ? And it's possibly a *good* thing that Phobos is only a static library, if it's not API/ABI-stable and ready... It's easier to handle the code bloat than the dll hell. But it does make for bigger executables than C++ does. The size of the wxD executables was ridiculous, though. :-P --anders
Re: Why Ruby?
On 12/21/10 2:38 PM, Bruno Medeiros wrote:
On 13/12/2010 15:49, Andrei Alexandrescu wrote:
On 12/13/10 9:11 AM, Jeff Nowakowski wrote:
On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
Yes I am :-)
Since you were the Descent author, I wonder how you feel about Ruby's
lack of static typing. In the video, the speaker bashes type safety as
"having your balls fondled at the airport", that is, security theater
that doesn't accomplish much.
By the way, I couldn't stop cringing at the distasteful, male-centric
sexual jokes that the talk is peppered with. Wonder if there was any
woman in the audience, and how she might have felt. And this is not a
ghetto rant - it's the keynote of a major Ruby conference! (And I'm
definitely not a prude.) Am I alone in thinking that this is not what
our metier should evolve into?
Besides, the argument in favor of dynamic typing is one of the most
disingenuous around. C is a language for consenting adults that gives
you that kind of freedom. If we took the speaker's arguments to their
logical conclusion, Ruby would be a language for people who don't care
about correctness, despise efficiency, and have contempt for modularity.
Ah, hold on a second. I agree the talk was rude and unprofessional (not
that it was meant to be either), but I disagree it was sexist or
offensive to women. Looking at the comment in question, "having your
balls fondled at the airport", it's simply something that you cannot
convey with anywhere the same meaning in a gender-neutral way ("having
your gonads fondled at the airports"?... "having your genitals fondled
at the airport"?... "having your crotch fondled at the airport"?...)
You presuppose there's a need to stick with the original metaphor. There
are many good metaphors to use, and there are a lot of good jokes around
the "porn scanners".
For better or worse, "balls" has become a metaphor for braveness,
boldness, power, recklessness, (or a combination therefore), and has
even been applied to women some times ("does she have the balls to do
that?").
There are a lot of actually good jokes around that topic. I think this
one, for example, is not gross at all: when describing the shortcomings
of iterators, I mentioned "you have to have a pair to do anything". I
delivered that with a straight face and it was really interesting to see
the audience slowly getting the doublespeak and starting to laugh with
various latencies. I am subjective but I think that one is firmly on the
opposite side of a thin line than the "fondled balls" joke.
Andrei
Re: custom AST library
"Andrej Mitrovic" wrote:
> That's why I think it might be a better idea to simply use "DSL
> blocks" throughout your code. Instead of having to mixin each
> template, you would only have one template where you have all the
> rules for your DSL:
>
> float a = 1 ;
> int n = 10 ;
> // more D code..
>
> mixin(MyDSL!(q{
>// Here you use the syntax defined by the "MyDSL" language
>float x = sum!(i=0:10; a*i) ;
>float y = sum!(i=1:n; i*prod!(j=0:i ; i+j);
>// More MyDSL code..
> }));
>
> // Here you use D syntax again, and D will know about float x and float y.
>
> Not to mention that you could potentially have some control over
> syntax highlighting (if you have a capable editor :p). For example you
> could write a little script in VIM which detects the use of "MyDSL!()"
> template, and highlights the code inside the block differently than
> the one outside the block.
Very interesting idea :), one note - sum!(...) in DSL is not template any
more, so one can change a design as he wants, say:
mixin(MyDSL_Impl(q{
float x = sum {i=0:10 ; a * i};
float y = sum {i=1:n; i*prod{j=0:i; i+j}} ;
}));
this MyDSL_Impl only scans for "name" "{" text "}" and replaces it with
mixin(nameImpl(q{text})) ;
User can put entire function body or even almost full module (if don't care
about compile time) into that DSL in order not to change from DSL to normal
code and back. One more thing to think about - how to show correct error
line number in there?
Re: Why Ruby?
retard wrote: "Book: You must always do A and should also prefer choices like B." "Me: why?" "Book: Just do it, don't think." A novice follows the rules because he is told to. A master follows the rules because he understands them. A guru breaks the rules because the rules don't always apply.
Re: Why Ruby?
Nick Sabalausky wrote: *Very* interesting observation. I agree. I hadn't thought about it that way, and thanks to Bruno for the insight.
Re: custom AST library
On 12/21/10, Alex_Dovhal wrote:
> User can put entire function body or even almost full module (if don't care
> about compile time) into that DSL in order not to change from DSL to normal
> code and back.
Yep. You could even take it a step further and use some form of escape
mechanism, which would leave D code alone but parse the rest of the
string as a DSL. E.g.:
mixin(MyDSL!(q{
$(D)
float a = 1 ;// will be mixed in as is
int n = 10 ;
void test(int t)
{
writeln(t);
}
$(/D) // end of D code
x = sum(i=0:10; a*i) ; // will be parsed and reconstructed as D code
y = sum(i=1:n; i*prod!(j=0:i ; i+j);
}));
So now you wouldn't have to write a lot of MyDSL blocks in-between D code.
> One more thing to think about - how to show correct error
> line number in there?
See
https://docs.google.com/leaf?id=0B-f1J0HiG2ovNmQzNzM1ODYtNDM3ZC00N2I4LWI2YmUtYTIyM2Y2MzcyZWIw&sort=name&layout=list&num=50&pli=1
, there's a unittests.d module in /src in the archive. It uses a
parameter that is default initialized to the line (size_t line =
__LINE__))
I guess from there you could chomp up your string into an array for
each new line, and if your DSL parser finds a syntax error it would
report the line number as e.g. currentLineNumber + line, where
currentLineNumber is the line number you're currently parsing, e.g.
DSLStringArray[currentLineNumber] << this line has the error.
I think that's about it (but I haven't had my nighttime coffee yet so
don't trust me fully on this one :p).
What's the problem in opensourcing htod?
Hello, Why don't You make htod opensource? I don't think it has commercial potential, or I'm wrong? I'm asking, because it's a shame that people who wants publish D bindings have to make their own scripts for that (so bindings can be generated on !windows too). If there are no chances for getting htod, maybe someone know decent binding generators (scripting languages preferred)? The ones, which I've been using are too bad (i.e. stripping out const from various places). Cheers, Mariusz Gliwiński signature.asc Description: This is a digitally signed message part.
Re: Why Ruby?
On 21/12/2010 21:24, Andrei Alexandrescu wrote:
On 12/21/10 2:38 PM, Bruno Medeiros wrote:
On 13/12/2010 15:49, Andrei Alexandrescu wrote:
On 12/13/10 9:11 AM, Jeff Nowakowski wrote:
On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
Yes I am :-)
Since you were the Descent author, I wonder how you feel about Ruby's
lack of static typing. In the video, the speaker bashes type safety as
"having your balls fondled at the airport", that is, security theater
that doesn't accomplish much.
By the way, I couldn't stop cringing at the distasteful, male-centric
sexual jokes that the talk is peppered with. Wonder if there was any
woman in the audience, and how she might have felt. And this is not a
ghetto rant - it's the keynote of a major Ruby conference! (And I'm
definitely not a prude.) Am I alone in thinking that this is not what
our metier should evolve into?
Besides, the argument in favor of dynamic typing is one of the most
disingenuous around. C is a language for consenting adults that gives
you that kind of freedom. If we took the speaker's arguments to their
logical conclusion, Ruby would be a language for people who don't care
about correctness, despise efficiency, and have contempt for modularity.
Ah, hold on a second. I agree the talk was rude and unprofessional (not
that it was meant to be either), but I disagree it was sexist or
offensive to women. Looking at the comment in question, "having your
balls fondled at the airport", it's simply something that you cannot
convey with anywhere the same meaning in a gender-neutral way ("having
your gonads fondled at the airports"?... "having your genitals fondled
at the airport"?... "having your crotch fondled at the airport"?...)
You presuppose there's a need to stick with the original metaphor. There
are many good metaphors to use, and there are a lot of good jokes around
the "porn scanners".
For better or worse, "balls" has become a metaphor for braveness,
boldness, power, recklessness, (or a combination therefore), and has
even been applied to women some times ("does she have the balls to do
that?").
There are a lot of actually good jokes around that topic. I think this
one, for example, is not gross at all: when describing the shortcomings
of iterators, I mentioned "you have to have a pair to do anything". I
delivered that with a straight face and it was really interesting to see
the audience slowly getting the doublespeak and starting to laugh with
various latencies. I am subjective but I think that one is firmly on the
opposite side of a thin line than the "fondled balls" joke.
Andrei
I forgot part of my argument actually: Just as the "balls" metaphor has
that meaning, conversely, "being grabbed by the balls" means kinda the
opposite: being subjugated, dominated, restrained, kept-under-control,
emasculated, etc.. So I think the "having your balls fondled at the
airport" is a direct allusion to that metaphor, which goes in line with
the talk's general theme of anti-authoritarianism.
So yes, I am presupposing there's a need to stick with the original
metaphor. (in order to convey the subjugation meaning/allusion.)
--
Bruno Medeiros - Software Engineer
Re: Why Ruby?
On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote: > retard wrote: > > "Book: You must always do A and should also prefer choices like B." > > > > "Me: why?" > > > > "Book: Just do it, don't think." > > A novice follows the rules because he is told to. > > A master follows the rules because he understands them. > > A guru breaks the rules because the rules don't always apply. So, is that a (possibly paraphrased) quote or just highly quotable? - Jonathan M Davis
Re: Why Ruby?
On 12/21/10 4:02 PM, Bruno Medeiros wrote:
On 21/12/2010 21:24, Andrei Alexandrescu wrote:
On 12/21/10 2:38 PM, Bruno Medeiros wrote:
On 13/12/2010 15:49, Andrei Alexandrescu wrote:
On 12/13/10 9:11 AM, Jeff Nowakowski wrote:
On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
Yes I am :-)
Since you were the Descent author, I wonder how you feel about Ruby's
lack of static typing. In the video, the speaker bashes type safety as
"having your balls fondled at the airport", that is, security theater
that doesn't accomplish much.
By the way, I couldn't stop cringing at the distasteful, male-centric
sexual jokes that the talk is peppered with. Wonder if there was any
woman in the audience, and how she might have felt. And this is not a
ghetto rant - it's the keynote of a major Ruby conference! (And I'm
definitely not a prude.) Am I alone in thinking that this is not what
our metier should evolve into?
Besides, the argument in favor of dynamic typing is one of the most
disingenuous around. C is a language for consenting adults that gives
you that kind of freedom. If we took the speaker's arguments to their
logical conclusion, Ruby would be a language for people who don't care
about correctness, despise efficiency, and have contempt for
modularity.
Ah, hold on a second. I agree the talk was rude and unprofessional (not
that it was meant to be either), but I disagree it was sexist or
offensive to women. Looking at the comment in question, "having your
balls fondled at the airport", it's simply something that you cannot
convey with anywhere the same meaning in a gender-neutral way ("having
your gonads fondled at the airports"?... "having your genitals fondled
at the airport"?... "having your crotch fondled at the airport"?...)
You presuppose there's a need to stick with the original metaphor. There
are many good metaphors to use, and there are a lot of good jokes around
the "porn scanners".
For better or worse, "balls" has become a metaphor for braveness,
boldness, power, recklessness, (or a combination therefore), and has
even been applied to women some times ("does she have the balls to do
that?").
There are a lot of actually good jokes around that topic. I think this
one, for example, is not gross at all: when describing the shortcomings
of iterators, I mentioned "you have to have a pair to do anything". I
delivered that with a straight face and it was really interesting to see
the audience slowly getting the doublespeak and starting to laugh with
various latencies. I am subjective but I think that one is firmly on the
opposite side of a thin line than the "fondled balls" joke.
Andrei
I forgot part of my argument actually: Just as the "balls" metaphor has
that meaning, conversely, "being grabbed by the balls" means kinda the
opposite: being subjugated, dominated, restrained, kept-under-control,
emasculated, etc.. So I think the "having your balls fondled at the
airport" is a direct allusion to that metaphor, which goes in line with
the talk's general theme of anti-authoritarianism.
So yes, I am presupposing there's a need to stick with the original
metaphor. (in order to convey the subjugation meaning/allusion.)
I'd almost agree had the word "fondled" been absent :o).
Andrei
Re: What's the problem in opensourcing htod?
On Tuesday, December 21, 2010 13:58:02 Mariusz Gliwiński wrote: > Hello, > Why don't You make htod opensource? I don't think it has commercial > potential, or I'm wrong? I'm asking, because it's a shame that people who > wants publish D bindings have to make their own scripts for that (so > bindings can be generated on !windows too). > If there are no chances for getting htod, maybe someone know decent binding > generators (scripting languages preferred)? The ones, which I've been using > are too bad (i.e. stripping out const from various places). Just so you know, htod works on wine. - Jonathan M Davis
Re: gdc-4.5 testing
Anders F Björklund wrote: > Neal Becker wrote: >>> AFAIK both shared libraries and x86_64 code have been working >>> for years with GDC, even though that is not the case with DMD. >>> >>> Phobos is still static, though. >>> >> But you can't link shared obj to static lib (Phobos), except on i386 - so >> you really can't use shared obj on x86_64 (if you need phobos). > > I don't get it, it shouldn't be that much different from a > static libstdc++ or something. You do need libgcc_s.so for > the exceptions to be thrown correctly, but otherwise your > application would be linking to Phobos anyway I thought... > > Do you have some more advanced example than the toy tests ? > > And it's possibly a *good* thing that Phobos is only a > static library, if it's not API/ABI-stable and ready... > It's easier to handle the code bloat than the dll hell. > But it does make for bigger executables than C++ does. > > The size of the wxD executables was ridiculous, though. :-P > > --anders IIUC, the issue isn't exactly shared vs static lib, it's linking -fPIC code to a lib that is non-PIC code. You can't link PIC code to non-PIC code except on i386. http://www.technovelty.org/code/c/amd64-pic.html
Re: try...catch slooowness?
Walter Bright wrote: > Michel Fortin wrote: >> Exceptions are slow, that's a fact of life. The idea is that an >> exception should be exceptional, so the case to optimize for is the >> case where you don't have any exception: a try...catch that doesn't >> throw. Other ways to implement exceptions exists which are faster at >> throwing (setjmp for instance), but they're also slower at entering >> and exiting a try..catch block when no exception occur. > > [...] > >> Exceptions are recommended to avoid cluttering your normal code flow >> with error handling code. Clearly, in the code above exceptions are >> part of the normal code flow. That's not what exception are made for. > > Right on all counts. Exceptions are for *exceptional* cases, i.e. > unexpected errors, not normal control flow. Exceptions (actual ones and not just a reference to any particular error handling mechanism) are EXPECTED errors. That follows directly from the goal of keeping programs running by handling of errors that were thought about at design time. Show me an unexpected error and I'll show you a bug. > > The implementation is designed so that the speed normal execution is > strongly favored over speed of exception handling.
Re: Why Ruby?
Jonathan M Davis wrote: On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote: retard wrote: "Book: You must always do A and should also prefer choices like B." "Me: why?" "Book: Just do it, don't think." A novice follows the rules because he is told to. A master follows the rules because he understands them. A guru breaks the rules because the rules don't always apply. So, is that a (possibly paraphrased) quote or just highly quotable? I heard it a very long time ago, and I do not know where it originated, or even if it wasn't just coined by my friends.
Re: What's the problem in opensourcing htod?
Dnia wtorek 21 grudzień 2010 o 23:08:34 Jonathan M Davis napisał(a): > On Tuesday, December 21, 2010 13:58:02 Mariusz Gliwiński wrote: > > Hello, > > Why don't You make htod opensource? I don't think it has commercial > > potential, or I'm wrong? I'm asking, because it's a shame that people who > > wants publish D bindings have to make their own scripts for that (so > > bindings can be generated on !windows too). > > If there are no chances for getting htod, maybe someone know decent > > binding generators (scripting languages preferred)? The ones, which I've > > been using are too bad (i.e. stripping out const from various places). > > Just so you know, htod works on wine. I know, but it's still not correct way to treat developers that are working with you on multiplatform project. That's why I'm searching for multiplatform solution. It's not like i am going to design by hack, at least starting point shouldn't force people to emulate other emulating system for updating dependencies. Cheers, Mariusz Gliwiński signature.asc Description: This is a digitally signed message part.
Re: try...catch slooowness?
Steven Schveighoffer wrote: > An exception is a recoverable error, Not necessarily. At some point, all the handling options could have been tried but all failed in which case there is nothing left to do except for letting something higher up (like the operating system) deal with the situation. In such a case, recovery did not occur if you consider recovery to mean that the program keeps running normally. > Exception handling is > great when it exists at a much higher level, because you can > essentially do all error handling in one spot, and simply write code > without worrying about error codes. That sounds like the common misconception that leads to weak designs.
Re: What's the problem in opensourcing htod?
Is htod a part of the C++ DM toolkit? I don't think it is, I mean it's only useful for the D language. Sooner or later Walter is either going to open-source it or we'll be forced to reinvent the tool. It's probably wouldn't be much work for a C-only header translator. On 12/21/10, Mariusz Gliwiński wrote: > Dnia wtorek 21 grudzień 2010 o 23:08:34 Jonathan M Davis napisał(a): >> On Tuesday, December 21, 2010 13:58:02 Mariusz Gliwiński wrote: >> > Hello, >> > Why don't You make htod opensource? I don't think it has commercial >> > potential, or I'm wrong? I'm asking, because it's a shame that people >> > who >> > wants publish D bindings have to make their own scripts for that (so >> > bindings can be generated on !windows too). >> > If there are no chances for getting htod, maybe someone know decent >> > binding generators (scripting languages preferred)? The ones, which I've >> > been using are too bad (i.e. stripping out const from various places). >> >> Just so you know, htod works on wine. > I know, but it's still not correct way to treat developers that are working > with you on multiplatform project. That's why I'm searching for > multiplatform > solution. It's not like i am going to design by hack, at least starting > point > shouldn't force people to emulate other emulating system for updating > dependencies. > > Cheers, > Mariusz Gliwiński >
Re: What's the problem in opensourcing htod?
"It's probably wouldn't". I need a new brand of coffee. -_- On 12/21/10, Andrej Mitrovic wrote: > Is htod a part of the C++ DM toolkit? I don't think it is, I mean it's > only useful for the D language. Sooner or later Walter is either going > to open-source it or we'll be forced to reinvent the tool. It's > probably wouldn't be much work for a C-only header translator. > > On 12/21/10, Mariusz Gliwiński wrote: >> Dnia wtorek 21 grudzień 2010 o 23:08:34 Jonathan M Davis napisał(a): >>> On Tuesday, December 21, 2010 13:58:02 Mariusz Gliwiński wrote: >>> > Hello, >>> > Why don't You make htod opensource? I don't think it has commercial >>> > potential, or I'm wrong? I'm asking, because it's a shame that people >>> > who >>> > wants publish D bindings have to make their own scripts for that (so >>> > bindings can be generated on !windows too). >>> > If there are no chances for getting htod, maybe someone know decent >>> > binding generators (scripting languages preferred)? The ones, which >>> > I've >>> > been using are too bad (i.e. stripping out const from various places). >>> >>> Just so you know, htod works on wine. >> I know, but it's still not correct way to treat developers that are >> working >> with you on multiplatform project. That's why I'm searching for >> multiplatform >> solution. It's not like i am going to design by hack, at least starting >> point >> shouldn't force people to emulate other emulating system for updating >> dependencies. >> >> Cheers, >> Mariusz Gliwiński >> >
Re: Why Ruby?
2010/12/21 Walter Bright : > Jonathan M Davis wrote: >> On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote: >>> A novice follows the rules because he is told to. >>> >>> A master follows the rules because he understands them. >>> >>> A guru breaks the rules because the rules don't always apply. >> >> So, is that a (possibly paraphrased) quote or just highly quotable? > > I heard it a very long time ago, and I do not know where it originated, or > even if it wasn't just coined by my friends. > I think it stems from a traditional Japanese model of learning, known as the Shu-Ha-Ri. As usual, Wikipedia gives a good overview. http://en.wikipedia.org/wiki/Shuhari
Re: What's the problem in opensourcing htod?
On 2010-12-21 16:58:02 -0500, Mariusz Gliwiński said: Hello, Why don't You make htod opensource? If I remember well, Walter said it includes parts of his C++ compiler (DMC), which he sells, is closed source, and has a long history. It's possible he does not have the right to license it as open source, or perhaps he just doesn't want to disclose the source for DMC. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: What's the problem in opensourcing htod?
Michel Fortin wrote: If I remember well, Walter said it includes parts of his C++ compiler (DMC), which he sells, is closed source, and has a long history. It's possible he does not have the right to license it as open source, or perhaps he just doesn't want to disclose the source for DMC. You can buy the source to DMC!
Re: What's the problem in opensourcing htod?
Mariusz Gliwiński wrote: Why don't You make htod opensource? htod is built out of the C and C++ compiler front end, the source of which Digital Mars sells.
Re: What's the problem in opensourcing htod?
22.12.2010 @ 03:17:31 Walter: > htod is built out of the C and C++ compiler front end, the source of which > Digital Mars sells. Thanks, I understand that. Why htod strips out const? 1) in: const int var = 2; out: null 2) in: DLL const char *func( int arg ); out: char * func(int arg); 3) in: DLL void func( int arg, const char *arg2 ); out: void func(int arg, const char *arg2); 4) there is const int * const and void func() const too, of course a) Are there any chances to fix it? b) If no, someone of You have seen tool that implements const's properly? (as I said, scripting language would be preferred, but anything appreciated) Cheers, Mariusz Gliwiński signature.asc Description: This is a digitally signed message part.
Re: What's the problem in opensourcing htod?
Mariusz Gliwiński wrote: Thanks, I understand that. Why htod strips out const? 1) in: const int var = 2; out: null 2) in: DLL const char *func( int arg ); out: char * func(int arg); 3) in: DLL void func( int arg, const char *arg2 ); out: void func(int arg, const char *arg2); 4) there is const int * const and void func() const too, of course a) Are there any chances to fix it? b) If no, someone of You have seen tool that implements const's properly? (as I said, scripting language would be preferred, but anything appreciated) htod was built for D1, and hasn't been updated for D2. Hence, there are some issues. But it cannot work perfectly, there'll usually be a bit of hand editing of the result.
Re: Why Ruby?
"Andrei Alexandrescu" wrote in message
news:ier8i4$1db...@digitalmars.com...
> On 12/21/10 4:02 PM, Bruno Medeiros wrote:
>> On 21/12/2010 21:24, Andrei Alexandrescu wrote:
>>> On 12/21/10 2:38 PM, Bruno Medeiros wrote:
On 13/12/2010 15:49, Andrei Alexandrescu wrote:
> On 12/13/10 9:11 AM, Jeff Nowakowski wrote:
>> On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
>>> Yes I am :-)
>>
>> Since you were the Descent author, I wonder how you feel about Ruby's
>> lack of static typing. In the video, the speaker bashes type safety
>> as
>> "having your balls fondled at the airport", that is, security theater
>> that doesn't accomplish much.
>
> By the way, I couldn't stop cringing at the distasteful, male-centric
> sexual jokes that the talk is peppered with. Wonder if there was any
> woman in the audience, and how she might have felt. And this is not a
> ghetto rant - it's the keynote of a major Ruby conference! (And I'm
> definitely not a prude.) Am I alone in thinking that this is not what
> our metier should evolve into?
>
> Besides, the argument in favor of dynamic typing is one of the most
> disingenuous around. C is a language for consenting adults that gives
> you that kind of freedom. If we took the speaker's arguments to their
> logical conclusion, Ruby would be a language for people who don't care
> about correctness, despise efficiency, and have contempt for
> modularity.
Ah, hold on a second. I agree the talk was rude and unprofessional (not
that it was meant to be either), but I disagree it was sexist or
offensive to women. Looking at the comment in question, "having your
balls fondled at the airport", it's simply something that you cannot
convey with anywhere the same meaning in a gender-neutral way ("having
your gonads fondled at the airports"?... "having your genitals fondled
at the airport"?... "having your crotch fondled at the airport"?...)
>>>
>>> You presuppose there's a need to stick with the original metaphor. There
>>> are many good metaphors to use, and there are a lot of good jokes around
>>> the "porn scanners".
>>>
For better or worse, "balls" has become a metaphor for braveness,
boldness, power, recklessness, (or a combination therefore), and has
even been applied to women some times ("does she have the balls to do
that?").
>>>
>>> There are a lot of actually good jokes around that topic. I think this
>>> one, for example, is not gross at all: when describing the shortcomings
>>> of iterators, I mentioned "you have to have a pair to do anything". I
>>> delivered that with a straight face and it was really interesting to see
>>> the audience slowly getting the doublespeak and starting to laugh with
>>> various latencies. I am subjective but I think that one is firmly on the
>>> opposite side of a thin line than the "fondled balls" joke.
>>>
>>>
>>> Andrei
>>
>> I forgot part of my argument actually: Just as the "balls" metaphor has
>> that meaning, conversely, "being grabbed by the balls" means kinda the
>> opposite: being subjugated, dominated, restrained, kept-under-control,
>> emasculated, etc.. So I think the "having your balls fondled at the
>> airport" is a direct allusion to that metaphor, which goes in line with
>> the talk's general theme of anti-authoritarianism.
>> So yes, I am presupposing there's a need to stick with the original
>> metaphor. (in order to convey the subjugation meaning/allusion.)
>
> I'd almost agree had the word "fondled" been absent :o).
>
This is what makes me question the existence of anti-female sexism in the
joke: Replace the word "balls" with either "breasts" or any slang (or
non-slang) term for female genitalia. Maybe replace the speaker with a
woman, too, I don't care, either way. Or keep the word "balls" and make the
speaker a woman. Any combination, whatever. Would that make it offensive to
men? Maybe I'm just really weird as far as men go, but I honestly can't see
how it would be. I certainly wouldn't take offense to it, no matter how you
arranged the male/female-ness. But I can certainly imagine people that would
still wave an "offensive to women" banner.
So unless I just have a really bad grasp of human behavior (and knowing me,
I very well might), what we have is a situation where references to any
gender-specific body part is offensive to...women and only women. Which
triggers the "Reductio ad absurdum" flag in my mind.
Re: Why Ruby?
"Walter Bright" wrote in message news:ier98d$1ec...@digitalmars.com... > Jonathan M Davis wrote: >> On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote: >>> retard wrote: "Book: You must always do A and should also prefer choices like B." "Me: why?" "Book: Just do it, don't think." >>> A novice follows the rules because he is told to. >>> >>> A master follows the rules because he understands them. >>> >>> A guru breaks the rules because the rules don't always apply. >> >> So, is that a (possibly paraphrased) quote or just highly quotable? > > I heard it a very long time ago, and I do not know where it originated, or > even if it wasn't just coined by my friends. Sounds a bit Zen Buddhist or maybe Taoist to me.
Re: Why Ruby?
"Steven Schveighoffer" wrote in message news:op.vn2zzvlceav...@steve-laptop... > On Tue, 21 Dec 2010 14:50:21 -0500, Bruno Medeiros > wrote: > >> In a less extreme view, it is not about controlling stupidity, but >> controlling creativity (a view popular amongst "artist"/"painter" >> programmers). So here the programmers are not dumb, but still they need >> to be kept in line with rules, constraints, specifications, strict APIs, >> etc.. You can't do anything too strange or out of the ordinary, and the >> language is a reflection of that, especially with regards to >> restrictions on dynamic typing (and other dynamic stuff like runtime >> class modification). > > Those aren't bugs, they are the artistic qualities of my program! It's a > statement on the political bias against bugs, I mean most people kill bugs > without a second thought! > Or even worse, they try to "fix" bugs...just like people will "fix" their pets, or how tyrants will "fix" their opposition or their scapegoats. Save the bugs! Thay have just as much a right to exist as any compiler or audio codec! Ok, I'm done now :)
Re: New syntax for string mixins
Alex_Dovhal wrote:
"Don" wrote:
In order for CTFE code to call pre-compiled code, three things are
required:
(1) the compiler needs to be able to find the file (.obj/.lib/shared
library) containing the compiled code;
(2) the compiler needs to be able to load the module and call it. This
requires some form of dynamic linking.
(3) We need a marshalling step, to convert from compiler literal to
compiled data, and back.
Step (3) is straightforward. The challenge is step(2), although note that
it's a general "allow the compiler to load a plugin" problem, and doesn't
have much to do with CTFE.
I thought it over, and got:
(1) can be solved by adding compiler option: --macro-libs=, so
the compiler knows in which dynamic libraries to search for the plugins ;
(2) plugin library functions should be *stdcall*, so C++ compiler can load
them. That library should implement function like that:
PluginInfo* getFunctionsInfo () ;
where:
typedef struct _PluginInfo{
struct _PluginInfo * nextPlugin ;
char* fcnName ; // short name of a function, e.g. "fcn"
char* params ; // param list, e.g. "(int, float, char*)"
char* mangledName;//name of funct. in the library, e.g. "_...@12"
char* returnType ; // e.g. "int"
bool isNothrow ; // if useful?
bool isPure ;// ditto
//... etc ...
} PluginInfo ;
And also should implement all the functions, info about which is returned by
getFunctionsInfo().
D compiler calls getFunctionsInfo from each plugin library - and then loads
all the implemented functions with full info about them.
If one plugin function name found in two or more libraries - D throws
compiler error.
Not a perfect solution, but at least straightforward one and solves given
problem.
One more note: this approach makes CTFE functions calling such plugins
uncallable at runtime, which IMO is OK, as one should not call it in any
case.
Is that suitable?
It's not that complicated. Once you can load the library and call *one*
function in it, the problem is solved.
But at a deeper level, I'm not sure what you'd hope to achieve with this.
I mean (excluding some not-yet implemented features), CTFE allows you to
execute any pure + safe function which you have source code for.
So, if you had such a plugin, it could do things like make database
queries. Everything else you can do already.
