Re: renamepalooza time
spir wrote: > On 01/23/2011 12:03 AM, Ali Çehreli wrote: > Sounds similar to > using whitespace for visual grouping like in > a*b + c*d > or > [ [1,2,3] , [4,5,6] ] > > But may be a bit too complicated for a public, free-willing, style, > don't you think? Rather for an enforced project or corporate one, I'd > say... Agreed, but I will keep using an underscore after "is". Another reason why I do so is, when used with camelcase, that little "is" capitalizes the next word just to be consistent with the camelcase part of the naming conventions. When we have an attribute of an object named 'ready', 'isReady()' doesn't match because 'ready' doesn't match 'Ready'. An underscore makes it stay lowercased: is_ready(); The attribute can follow the camelcase rule and be consistent with the rest of the names: is_lastItem(); Ali
Re: Potential patent issues
On Sat, 2011-01-22 at 15:54 -0500, Jean Crystof wrote: > Nick Sabalausky Wrote: > > > I've been under the impression that, as a rule, the USPTO doesn't check for > > prior art and deliberately leaves "invalid due to prior art" up to the > > courts. > > That's how it works. The patent threat is always there. Someone can > patent delegates, classes, and whatever language feature whenever they > want. In the courts if Walter is much poorer than the competitor, he > can't win. The SCO case was a great example. They didn't own the Unix > rights and couldn't find any patent infringing code. Nevertheless, the > Microsoft money kept them fighting. If Apple or Microsoft wants to > compete with Walter, he simply can't win. Isn't this why the US system of software patents is wrong? "Big Money" keeps insisting that the whole patent system is designed to allow people who have inventions but not the resources to exploit them, a route to obtaining remuneration by allowing others to do the exploitation. This has always been a specious argument. Even if it were not, and whatever the original use of letters patent that led to the patent system, this system, especially in the USA, has turned into a business tool for "Big Money" to ensure control of all exploitation is handled by "Big Money". To preserve power in the hands of "Big Money" the patent system has been evolved into a game that only "Big Money" can play, small players are systematically excluded. (Of course, lawyers are the only real winners as they get paid win or lose.) Where the invention is something that can only be exploited by there being something physical that must be manufactured, then there are arguments that patents are a useful tool. Where the invention is a business process or a software technique (or a user interface technique?) then I don't see that it serves any purpose other than preservation of control by "Big Money" over innovation. The exact opposite of the avowed purpose of patents. I have yet to see how business processes, algorithms, and programming techniques are anything other than ideas or mathematics, and ideas and mathematics are supposed to be not patentable. As far as I am aware the UK Patent Office still does not issue software patents, though the EU Patent Office, seems to have started to try, under pressure from "Big Money" I suspect. (I agree it is easy to blame US companies and ignore the fact that European and Asian companies are part of the cartel when Microsoft, IBM, HP, etc. are the easy names to roll off the tongue, so "Big Money" here does not mean large US corporate.) Sadly, the Anti-Counterfeiting Trade Agreement (ACTA -- cf. http://en.wikipedia.org/wiki/Anti-Counterfeiting_Trade_Agreement) appears to have been somewhat hijacked by US "Big Money" via the US Trade Representative (USTR -- cf. http://www.ustr.gov/) as a tool for imposing the US way of patents onto the rest of the world (*). This means software patents will have to be granted everywhere that ACTA applies. No matter how much lobbying the FLOSS community do, I bet "Big Money" will not fail to sieze the opportunity to ram through the whole "software techniques are not ideas, they are patentable" philosophy. Perhaps then the only defence these days, especially in the USA, and sadly if ACTA is signed into place, the rest of the world, is to be a signatory to the Open Invention Network (OIN -- cf. http://www.openinventionnetwork.com/). However appealing though, even this is just a tool for "Big Money" since only by having significant resources can you actually patent something that you can then magnanimously donate to the OIN patent pool -- have you noticed that "Big Money" is very selective about which patents get donated and which don't? So it seems the only hope for small players to do any innovation, indeed any work, in the software arena, is to be ignorable by "Big Money", i.e. do stuff that doesn't matter or doesn't constitute a threat to "Big Money". Either that or the policitians of the world spontaneously see the light, that they are being herded by "Big Money", and disallow software patents forever. All in all though it seems the days of the small independent software development organization doing anything innovative are strictly limited. (*) You might want to follow Simon Phipps (Wild Webmink) on this http://webmink.com/2010/03/19/acta-roundup/ -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Casting between delegates with qualified value type parameters
"Sean Eskapp" wrote in message news:ih9rhr$2c1k$1...@digitalmars.com... > > Is there a reason for this, or is it a bug? Sounds like it could be http://d.puremagic.com/issues/show_bug.cgi?id=3797 All sorts of implicit conversions are currently allowed between function pointers that shouldn't be.
Re: renamepalooza time
On 01/23/2011 09:13 AM, Ali Çehreli wrote: Agreed, but I will keep using an underscore after "is". Another reason why I do so is, when used with camelcase, that little "is" capitalizes the next word just to be consistent with the camelcase part of the naming conventions. When we have an attribute of an object named 'ready', 'isReady()' doesn't match because 'ready' doesn't match 'Ready'. An underscore makes it stay lowercased: is_ready(); The attribute can follow the camelcase rule and be consistent with the rest of the names: is_lastItem(); You're right, it's a nice convention. Deins -- _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On 01/23/2011 06:21 AM, Andrei Alexandrescu wrote:
On 1/22/11 10:59 PM, Jonathan M Davis wrote:
This will be a _fantastic_ function to have. I think that I probably even have
an enhancement request somewhere that includes such a function. It's far too
common that you have to find something and you want both what is before and
after
the point that you find. Now, that being the case, I'd probably more commonly
find
it useful to get the part before what was found and then the part beginning with
what was found, but this works too.
I suspect there might be a simple and intuitive way to define a family of
functions that give you whatever portions of the find you're interested in
(before, match, after, before and match, match and after). That could be either
a naming convention or a template argument. Any ideas, let me know.
Andrei
Guess (tell me if I'm wrong) english says "cut into pieces". Thus, I would
consider a paradigm starting with either cut- or piece-/pieces-.
I still find that find- (!) is wrong for funcs like findParts, even
knowing the current find function actually returns the part match-and-after.
Actually, it's find trying to do too much imo, should just return the (first)
match; what anybody else would expect, or what? Thus, the name does not fit,
the semantics is unexpected, and weird errors are to come.
auto bigNumber = find!("a>10")(numbers); // too bad!
// Next applicant, please ;-)
Note I'm not at all against Andrei's generalised algos --on the contrary. But
having them too smart at the price of beeing counter-intuitive is wrong imo.
Denis
_
vita es estrany
spir.wikidot.com
detecting classes, structs, arrays in templates
Hi,
I want to specialize a template function - call it print() - for three
cases: classes, structs and arrays. Ideally I'd like something that
looks 'functional' like a proper specialization, but perhaps I need to
use "static if". I'm still at the beginning of my journey with D so I'd
be grateful for any pointers (sorry - that's a terrible pun). Perhaps
there's a corner of the D2 docs I've glossed over.
Thanks,
Luke
// in words you can understand...
void print(T)() {writefln("general");}
// But what does my specialization look like for all (or any)
// of the implementations of print() for the calls below.
int main() {
C c;// some class
S s;// some struct
int a[4]; // an array
int p;// a primitive type
print(c); // writefln("class");
print(s); // writefln("struct");
print(a); // writefln("array");
print(p); // writefln("primitive");
return 0;
}
Re: eliminate junk from std.string?
On 01/11/2011 07:17 PM, Jonathan M Davis wrote:
> Renaming a function and having a deprecated alias to the old name for a few
> releases eases the transition would definitely be good practice. aliasing a
> function just to have another name for the same thing wouldn't be good
> practice.
> There has to be a real benefit to having the second name. Providing a smooth
> deprecation route would be a case where there's a real benefit.
How about wrapping the aliases up in, e.g., std.compatibility.{c,
javascript, python, …}
Well, maybe not in std; that might imply a commitment to keep up-to-date
full library compatibility forever. But it might make a semi-useful
contrib library.
--Joel
Re: detecting classes, structs, arrays in templates
Luke J. West wrote:
Hi,
I want to specialize a template function - call it print() - for three
cases: classes, structs and arrays. Ideally I'd like something that
looks 'functional' like a proper specialization, but perhaps I need to
use "static if". I'm still at the beginning of my journey with D so I'd
be grateful for any pointers (sorry - that's a terrible pun). Perhaps
there's a corner of the D2 docs I've glossed over.
Thanks,
Luke
// in words you can understand...
void print(T)() {writefln("general");}
// But what does my specialization look like for all (or any)
// of the implementations of print() for the calls below.
int main() {
C c;// some class
S s;// some struct
int a[4]; // an array
int p;// a primitive type
print(c); // writefln("class");
print(s); // writefln("struct");
print(a); // writefln("array");
print(p); // writefln("primitive");
return 0;
}
You want to have a look-see at isExpressions[1]:
void print(T)(T t) if (is(T == class)){
writeln("class");
}
void print(T)(T t) if (is(T == struct)){
writeln("struct");
}
void print(T)(T t) if (is(T U == U[])){
writeln("array");
}
void print(T)(T t) if (isNumeric!T || isSomeChar!T){
writeln("primitive");
}
Haven't actually tested these, as I don't have D here.
Note also that two specializations are missing - pointer
and associative array:
void print(T)(T t) if (is(T U == U[V], V)){
writeln("associative array");
}
void print(T)(T t) if (is(T U == U*)){
writeln("pointer");
}
http://digitalmars.com/d/2.0/expression.html#IsExpression
--
Simen
Re: detecting classes, structs, arrays in templates
Luke J. West:
> Hi,
>
> I want to specialize a template function - call it print() - for three
> cases: classes, structs and arrays. Ideally I'd like something that
> looks 'functional' like a proper specialization, but perhaps I need to
> use "static if". I'm still at the beginning of my journey with D so I'd
> be grateful for any pointers (sorry - that's a terrible pun). Perhaps
> there's a corner of the D2 docs I've glossed over.
I suggest you to ask such questions in the D.learn newsgroup.
Here are two possible implementations:
import std.stdio: writeln;
import std.traits: isArray;
void print(T)(T x) if (!isArray!T && !is(T == class) && !is(T == struct)) {
writeln("general");
}
void print(T)(T[] x) {
writeln("Dynamic array or fixed-sized array");
}
void print(T)(T x) if (is(T == class)) {
writeln("Class instance");
}
void print(T)(T x) if (is(T == struct)) {
writeln("Struct instance");
}
void print2(T)(T x) {
static if (isArray!T)
writeln("Dynamic array or fixed-sized array");
else static if (is(T == class))
writeln("Class instance");
else static if (is(T == struct))
writeln("Struct instance");
else
writeln("general");
}
class C {}
struct S {}
void main() {
C c; // some class
S s; // some struct
int[4] a; // a fixed-sized array
int p;// a primitive type
print(a);
print(p);
print(c);
print(s);
writeln();
print2(a);
print2(p);
print2(c);
print2(s);
}
Bye,
bearophile
Re: detecting classes, structs, arrays in templates
Thanks for that bearophile - I'll get myself subscribed right away.
Bye for now,
Luke
On Sun, 23 Jan 2011 09:17:05 -0500, "bearophile"
said:
> Luke J. West:
>
> > Hi,
> >
> > I want to specialize a template function - call it print() - for three
> > cases: classes, structs and arrays. Ideally I'd like something that
> > looks 'functional' like a proper specialization, but perhaps I need to
> > use "static if". I'm still at the beginning of my journey with D so I'd
> > be grateful for any pointers (sorry - that's a terrible pun). Perhaps
> > there's a corner of the D2 docs I've glossed over.
>
> I suggest you to ask such questions in the D.learn newsgroup.
> Here are two possible implementations:
>
> import std.stdio: writeln;
> import std.traits: isArray;
>
> void print(T)(T x) if (!isArray!T && !is(T == class) && !is(T == struct))
> {
> writeln("general");
> }
>
> void print(T)(T[] x) {
> writeln("Dynamic array or fixed-sized array");
> }
>
> void print(T)(T x) if (is(T == class)) {
> writeln("Class instance");
> }
>
> void print(T)(T x) if (is(T == struct)) {
> writeln("Struct instance");
> }
>
> void print2(T)(T x) {
> static if (isArray!T)
> writeln("Dynamic array or fixed-sized array");
> else static if (is(T == class))
> writeln("Class instance");
> else static if (is(T == struct))
> writeln("Struct instance");
> else
> writeln("general");
> }
>
>
> class C {}
> struct S {}
>
> void main() {
> C c; // some class
> S s; // some struct
> int[4] a; // a fixed-sized array
> int p;// a primitive type
>
> print(a);
> print(p);
> print(c);
> print(s);
> writeln();
>
> print2(a);
> print2(p);
> print2(c);
> print2(s);
> }
>
> Bye,
> bearophile
Unilink - alternative linker for win32/64, DMD OMF extensions?
After hitting some troubles with optlink in the past (though my problems
got solved others may be not)
I was in constant search for alternatives.
The good news:
there *do* happen to be very versatile linker for windows able to
produce 32/64bit PE, that supports OMF format and so on. Another cool
thing that has is so called mix-mode linking i.e. linking objects
produced by different compilers with different RTLs (tricky but might
worth the effort).
Link to ftp with docs and binary: ftp://ftp.styx.cabel.net/pub/UniLink/
According to author it does fully support DMC++ along with a huge pack
of other C++ compilers.
Now the bad news:
it doesn't quite work with DMD for the moment. It's able to link test.d,
but fails to link test2.d. (see attach) Stating that the resulting OMF
is invalid. I asked the developer about it, his reply:
/reply
DM is in list of supported compilers (with DM C extensions). But D
extension in sample is suspicious. There it attempt to define "select
any" comdat that referenced to TLS-type segment. This is similar to common
backend error. Another possibility is that it is an D "extension". But
we don't possess documentation of D object format extensions and only
can gess what it is.
If the D becomes common used language we can "examine" its new
features and take in into consideration. But... Maybe is's easier to
contact with D developer and ask for new features in objects.
/end reply
QUESTION
--->>>
So here I am asking what kind of OMF extensions DMD uses, and what's difference
between test.d and test2.d in terms of object file output?
<<<---
Any hints on where to look for them are also welcome.
If they are minor then we can convince the developer
and have 64bit linker to experiment with on windows.
NOTES
I used dmd 2.051, though with 2.050 it's the same issue;
command line:
dmd -c.d
For those interested in experimenting with unilink themselves,
use the following config (ulink.cfg) adjusting the path to dmd as needed:
-zkernel32;advapi32;user32;wsock32;shell32;snn.lib
-LC:\dmd2\windows\lib
-Go
Then linking is just: ulink .obj
--
Dmitry Olshansky
import std.stdio;
void main(){
writeln("Hello world!\n");
}import std.stdio;
void main(){
// auto magic = A!(int)(42);
writeln(32);
}
Opt-out closures
I get errors when working with nested functions and structs or scoped classes, because closures can't be used with anything with scoped destruction. This makes complete sense, but I don't even want the closure functionality of these nested functions. Personally, I would like to be able to opt-out of the closure functionality of nested functions: if the enclosing function exits, and a nested function thereof is called, then a segfault would occur when it tried to access the stack of its enclosing function; however, access of scoped-destruction variables from an enclosing-scope function would be fine. Thoughts? The not-being-able-to-access-scoped-destruction-variables thing is really getting to me, since one of the main driving features I like about D is the ability to use anonymous and nested functions.
Re: Opt-out closures
On Sunday 23 January 2011 06:36:27 Sean Eskapp wrote: > I get errors when working with nested functions and structs or scoped > classes, because closures can't be used with anything with scoped > destruction. This makes complete sense, but I don't even want the closure > functionality of these nested functions. Personally, I would like to be > able to opt-out of the closure functionality of nested functions: if the > enclosing function exits, and a nested function thereof is called, then a > segfault would occur when it tried to access the stack of its enclosing > function; however, access of scoped-destruction variables from an > enclosing-scope function would be fine. > > Thoughts? The not-being-able-to-access-scoped-destruction-variables thing > is really getting to me, since one of the main driving features I like > about D is the ability to use anonymous and nested functions. If a nested function is marked as static, then it results in a function rather than a delegate. Of course, that means that you can't access the enclosing scope, but if you don't care about that, then just use static. - Jonathan M Davis
Re: Opt-out closures
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > On Sunday 23 January 2011 06:36:27 Sean Eskapp wrote: > > I get errors when working with nested functions and structs or scoped > > classes, because closures can't be used with anything with scoped > > destruction. This makes complete sense, but I don't even want the closure > > functionality of these nested functions. Personally, I would like to be > > able to opt-out of the closure functionality of nested functions: if the > > enclosing function exits, and a nested function thereof is called, then a > > segfault would occur when it tried to access the stack of its enclosing > > function; however, access of scoped-destruction variables from an > > enclosing-scope function would be fine. > > > > Thoughts? The not-being-able-to-access-scoped-destruction-variables thing > > is really getting to me, since one of the main driving features I like > > about D is the ability to use anonymous and nested functions. > If a nested function is marked as static, then it results in a function rather > than a delegate. Of course, that means that you can't access the enclosing > scope, but if you don't care about that, then just use static. > - Jonathan M Davis I want to be able to access the enclosing scope, but NOT after the function has exited; I should have the option of accessing the enclosing scope, but at the cost of making my delegate not a closure.
Re: Opt-out closures
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Sean Eskapp:
> > I want to be able to access the enclosing scope, but NOT after the function
> > has
> > exited; I should have the option of accessing the enclosing scope, but at
> > the cost
> > of making my delegate not a closure.
> It seems a worth thing to ask for. A possible syntax (not currently
> supported):
> void foo() {
> scope void bar() {}
> }
> Bye,
> bearophile
That looks like one of the best options syntax-wise. Nice!
Re: Opt-out closures
Sean Eskapp:
> I want to be able to access the enclosing scope, but NOT after the function
> has
> exited; I should have the option of accessing the enclosing scope, but at the
> cost
> of making my delegate not a closure.
It seems a worth thing to ask for. A possible syntax (not currently supported):
void foo() {
scope void bar() {}
}
Bye,
bearophile
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
On 01/14/2011 09:34 AM, Steven Schveighoffer wrote: > Is it common to have multiple modifiers on a single character? The > problem I see with using decomposed canonical form for strings is that > we would have to return a dchar[] for each 'element', which severely > complicates code that, for instance, only expects to handle English. Hebrew: • Almost every letter in a printed Hebrew bible has at least one of— ‣ vowel marker (the Hebrew alphabet is otherwise consonantal) and ‣ a /dagesh/ dot, indicating the difference between /b/ & /v/, or between /mm/ and /m/; • almost every word has at least one letter with a cantillation mark in addition to the above; and • other marks too complicated & off-topic to explain. Vietnamese uses Latin letters with accents playing multiple roles, so there are often two or three accent marks on a single letter; e.g., the name of the creator of pdfTeX is spelled “Hàn Thế Thành”, with two accents on the “e”. I’m sure there are others. —Joel
Re: replaceFirst, findPieces, and takeExactly
On 1/23/11 1:22 AM, Jim wrote: Andrei Alexandrescu Wrote: I suspect there might be a simple and intuitive way to define a family of functions that give you whatever portions of the find you're interested in (before, match, after, before and match, match and after). That could be either a naming convention or a template argument. Any ideas, let me know. splitAt splitBefore splitAfter ? That's a good suggestion, thanks. One issue is that if the element type of the range is integral, there is confusion (did you mean to split at position k?). I decided to go with these: http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html#findSplit Andrei
Re: renamepalooza time
On 2011-01-21, Jonathan M Davis wrote: > tr? The name means nothing to me. I haven't a clue where the name comes from, > so > I can't really give a better version of the same name. As it is, tr seems > fine to > me, particularly since tR just seems stupid. It should probably get a more > descriptive name though. replaceChars? Just for everyone's info. tr is a standard unix command; been around forever, and it is a mnemonic for 'translate'. It's also in perl. tr A-Z a-z # convert to lower-case Perl: $ph =~ tr/0-9/cd # get only the digits from a phone number entry field.
Re: replaceFirst, findPieces, and takeExactly
On Sunday 23 January 2011 07:12:34 Andrei Alexandrescu wrote: > On 1/23/11 1:22 AM, Jim wrote: > > Andrei Alexandrescu Wrote: > >> I suspect there might be a simple and intuitive way to define a family > >> of functions that give you whatever portions of the find you're > >> interested in (before, match, after, before and match, match and after). > >> That could be either a naming convention or a template argument. Any > >> ideas, let me know. > > > > splitAt > > splitBefore > > splitAfter > > > > ? > > That's a good suggestion, thanks. One issue is that if the element type > of the range is integral, there is confusion (did you mean to split at > position k?). > > I decided to go with these: > > http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html#fi > ndSplit That definitely seems like a good solution. - Jonathan M Davis
Re: renamepalooza time
On Sunday 23 January 2011 07:12:16 Brad wrote: > On 2011-01-21, Jonathan M Davis wrote: > > tr? The name means nothing to me. I haven't a clue where the name comes > > from, so I can't really give a better version of the same name. As it > > is, tr seems fine to me, particularly since tR just seems stupid. It > > should probably get a more descriptive name though. replaceChars? > > Just for everyone's info. > > tr is a standard unix command; been around forever, > and it is a mnemonic for 'translate'. > > It's also in perl. > > tr A-Z a-z # convert to lower-case > Perl: $ph =~ tr/0-9/cd # get only the digits from a phone number entry > field. Good to know. I know a number of unix/linux commands, but there always seems to be more of them... Not that that's a bad thing. - Jonathan M Davis
Re: Opt-out closures
On Sun, Jan 23, 2011 at 9:08 AM, bearophile wrote:
> Sean Eskapp:
>
> > I want to be able to access the enclosing scope, but NOT after the
> function has
> > exited; I should have the option of accessing the enclosing scope, but at
> the cost
> > of making my delegate not a closure.
>
> It seems a worth thing to ask for. A possible syntax (not currently
> supported):
>
> void foo() {
>scope void bar() {}
> }
>
>
I don't like being too negative, but if we're removing "scope" as a storage
class because it can leave unsafe dangling pointers, how likely is it that
we'll get delegates that can have dangling pointers?
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Yeah I can reproduce the same thing as you have. I did manage to convert an OMF to COFF file format, and link it with GCC (MinGW). See my thread here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=127079 I have yet to try it on more complex examples though. Give it a try and let me know if it works? :)
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Perhaps this page would be helpful for the linker guys: http://www.digitalmars.com/d/2.0/abi.html
Re: druntime !!!!
== Quote from Brad Roberts (bra...@puremagic.com)'s article > On 1/22/2011 4:32 PM, Robert Clipsham wrote: > > On 22/01/11 23:58, bioinfornatics wrote: > >> They are something wrong with druntime management!!! > >> Why druntime do not support gdc or ldc2? > >> Its is very crap thing i hope druntime will add soon gdc support. We can send > >> ldc and gdc patch. > >> Thanks for all > >> > >> best regards > > > > I've been talking to you on IRC about this, but I'll reiterate it here for > > everyone elses benefit. Having support for each compiler in druntime is a > > bad > > idea. This is what druntime did initially when it was forked from tango. The > > trouble was that as the compiler got updated, the runtime needed to be updated > > too, and the compiler and runtime became out of sync very easily, and > > getting > > everything up to date again was a pain. > > > > The solution to this is to have each compiler maintain its own druntime > > compiler-specifics, and have the non-compiler-specific code in a main druntime > > repository - this way all that is needed is to copy/paste the compiler specific > > code into druntime. This works, as when the compiler is updated, so is the > > compiler-specific portion of druntime and nothing gets out of sync. > > > > Of course, a lot of druntime isn't compiler specific, for these parts > > patches > > should probably be applied. I'm not entirely sure where gdc and ldc are with > > respect to this kind of patch, I know they both have complete druntime > > implementations, but I'm sure if this kind of patch was made (preferably in > > smaller, individual patches for each feature/bug etc) it would be applied. > > > > Of course, this is just the situation as I see it, and from memory, the druntime > > folk will probably chime in and give the full story. > > > Personally, I'd like to see one common runtime, but to achieve that requires > that the compiler/runtime interface be essentially the same between the > compilers. That's an achievable goal, but it has to actually be an agreed > upon > goal. Today, both gdc and ldc's interface with the runtime don't match dmd's. > So, where do they differ today? Why? Can they evolve to a common interface? > I'll happily apply patches from anyone providing them that work to achieve > that > goal. Please use bugzilla to submit them. > One implied part of this goal is that dmd is, while an important stake holder, > needs to play nice too. Changes need to go through a discussion round before > being made.. no unilateral changes. > Also, this discussion should probably drift over to the > d-runt...@puremagic.com > mailing list.. at least the parts that are directly related to accomplishing the > changes. > My 2 cents, > Brad I'm not sure where to find / subscribe to the mailing list, so I posted here: http://d.puremagic.com/issues/show_bug.cgi?id=5478 Regards.
Re: Opt-out closures
Andrew Wiley: > I don't like being too negative, but if we're removing "scope" as a storage > class because it can leave unsafe dangling pointers, how likely is it that > we'll get delegates that can have dangling pointers? I have written that without too much thinking, so I'm sure that's not a perfect idea :-) Regarding "scope" for classes, it is deprecated, instead of improving it, but the currently alternative solution is _less_ safe than the scope, and it's more buggy: http://d.puremagic.com/issues/show_bug.cgi?id=5115 A Java VM like the Oracle one has the best GC, plus escape analysis that allows it to stack-allocate some class instances. Currently D compilers have a far worse GC and even LDC-LLVM escape analysis is weak and it doesn't do much for D class instances. In my opinion D and its compilers need to perform that stack optimization by themselves, or the programmer needs to be "empowered" with some good, efficient and as much safe as possible way to stack allocate a class instance. At the moment D has none of both. Good luck with a slow system language :-) Bye, bearophile
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
On 23.01.2011 20:43, Andrej Mitrovic wrote: Yeah I can reproduce the same thing as you have. I did manage to convert an OMF to COFF file format, and link it with GCC (MinGW). See my thread here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=127079 I have yet to try it on more complex examples though. Give it a try and let me know if it works? :) Well after a pass through omf2d, the ulink says about the resulting obj: Fatal: Entry point must be specified So, yes it strips something, yet it's no longer an invalid OMF ;) Anyhow after jumping though some hoops with objconv I got ld to linktime, but it gets a pack of unresolved externals from D's runtime/phobos and I don't think converting them all is wise idea. -- Dmitry Olshansky
Can your programming language do this?
alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User;
// sql source code , table to fetch
void main() {
auto obj = new User(null); // that null should actually be a db handle if
you want to be able to commit changes
// read/write access to the user table, with compile time
// type and name checks
obj.first = "Changing my name!";
obj.date_last_edited = getUTCtime();
obj.commitChanges(); // save your writes back to the database,
(reasonably) efficiently
}
D can! It can dynamically make those DataObjects too, with the
same syntax, but you lose compile time checks for obvious reasons.
I just couldn't help but laugh a bit when I ran this thing through
CTFE and found it actually worked, so figured I'd share a positive
message with you guys :-)
See my code here:
http://arsdnet.net/dcode/database.d
You might want a database implementation to play with too:
http://arsdnet.net/dcode/mysql.d (best for this purpose so far)
http://arsdnet.net/dcode/sqlite.d (but the others work too)
http://arsdnet.net/dcode/postgres.d
A simple db.sql file is here:
http://arsdnet.net/dcode/db.sql
It's just a list of CREATE TABLE commands. I ran the program over
a far more complex file too and it worked, but it isn't a super
smart parser so you can probably break it pretty easily. (for one,
it is case sensitive where as standard SQL is not)
Re: Can your programming language do this?
Adam D. Ruppe wrote:
alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User;
// sql source code , table to fetch
void main() {
auto obj = new User(null); // that null should actually be a db
handle if
you want to be able to commit changes
// read/write access to the user table, with compile time
// type and name checks
obj.first = "Changing my name!";
obj.date_last_edited = getUTCtime();
obj.commitChanges(); // save your writes back to the database,
(reasonably) efficiently
}
D can! It can dynamically make those DataObjects too, with the
same syntax, but you lose compile time checks for obvious reasons.
I just couldn't help but laugh a bit when I ran this thing through
CTFE and found it actually worked, so figured I'd share a positive
message with you guys :-)
This is awesome. I've known that D could do it, and I've occasionally
poked at it myself, but always felt it was too much work for
something that isn't all that hard to do by hand. Now, getting
someone else to do it for me...
--
Simen
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Yeah, we're kind of stuck with Optlink for now.
Re: Opt-out closures
2011/1/23 Sean Eskapp :
> I want to be able to access the enclosing scope, but NOT after the function
> has
> exited; I should have the option of accessing the enclosing scope, but at the
> cost
> of making my delegate not a closure.
>
Until we have a dedicated syntax for it, I think you can use this hack:
import std.traits;
auto scopeDelegate(D)(scope D d) if (isDelegate!D)
{
return d;
}
int main()
{
StructWithDtor s;
trustedFunction(scopeDelegate({s.a = 5;}); // No heap allocation
}
Torarin
Re: druntime !!!!
On 1/23/2011 9:56 AM, Iain Buclaw wrote: > == Quote from Brad Roberts (bra...@puremagic.com)'s article >> On 1/22/2011 4:32 PM, Robert Clipsham wrote: >>> On 22/01/11 23:58, bioinfornatics wrote: They are something wrong with druntime management!!! Why druntime do not support gdc or ldc2? Its is very crap thing i hope druntime will add soon gdc support. We can > send ldc and gdc patch. Thanks for all best regards >>> >>> I've been talking to you on IRC about this, but I'll reiterate it here for >>> everyone elses benefit. Having support for each compiler in druntime is a >>> bad >>> idea. This is what druntime did initially when it was forked from tango. The >>> trouble was that as the compiler got updated, the runtime needed to be > updated >>> too, and the compiler and runtime became out of sync very easily, and >>> getting >>> everything up to date again was a pain. >>> >>> The solution to this is to have each compiler maintain its own druntime >>> compiler-specifics, and have the non-compiler-specific code in a main > druntime >>> repository - this way all that is needed is to copy/paste the compiler > specific >>> code into druntime. This works, as when the compiler is updated, so is the >>> compiler-specific portion of druntime and nothing gets out of sync. >>> >>> Of course, a lot of druntime isn't compiler specific, for these parts >>> patches >>> should probably be applied. I'm not entirely sure where gdc and ldc are with >>> respect to this kind of patch, I know they both have complete druntime >>> implementations, but I'm sure if this kind of patch was made (preferably in >>> smaller, individual patches for each feature/bug etc) it would be applied. >>> >>> Of course, this is just the situation as I see it, and from memory, the > druntime >>> folk will probably chime in and give the full story. >>> >> Personally, I'd like to see one common runtime, but to achieve that requires >> that the compiler/runtime interface be essentially the same between the >> compilers. That's an achievable goal, but it has to actually be an agreed >> upon >> goal. Today, both gdc and ldc's interface with the runtime don't match >> dmd's. >> So, where do they differ today? Why? Can they evolve to a common interface? >> I'll happily apply patches from anyone providing them that work to achieve >> that >> goal. Please use bugzilla to submit them. >> One implied part of this goal is that dmd is, while an important stake >> holder, >> needs to play nice too. Changes need to go through a discussion round before >> being made.. no unilateral changes. >> Also, this discussion should probably drift over to the >> d-runt...@puremagic.com >> mailing list.. at least the parts that are directly related to accomplishing > the >> changes. >> My 2 cents, >> Brad > > I'm not sure where to find / subscribe to the mailing list, so I posted here: > http://d.puremagic.com/issues/show_bug.cgi?id=5478 > > Regards. Lists: http://lists.puremagic.com I like the summary of problems, I dislike that it's more than one report per bug. It makes dealing with them a royal pain. One issue per bug please.
Re: druntime !!!!
On 2011-01-23 18:56, Iain Buclaw wrote: == Quote from Brad Roberts (bra...@puremagic.com)'s article On 1/22/2011 4:32 PM, Robert Clipsham wrote: On 22/01/11 23:58, bioinfornatics wrote: They are something wrong with druntime management!!! Why druntime do not support gdc or ldc2? Its is very crap thing i hope druntime will add soon gdc support. We can send ldc and gdc patch. Thanks for all best regards I've been talking to you on IRC about this, but I'll reiterate it here for everyone elses benefit. Having support for each compiler in druntime is a bad idea. This is what druntime did initially when it was forked from tango. The trouble was that as the compiler got updated, the runtime needed to be updated too, and the compiler and runtime became out of sync very easily, and getting everything up to date again was a pain. The solution to this is to have each compiler maintain its own druntime compiler-specifics, and have the non-compiler-specific code in a main druntime repository - this way all that is needed is to copy/paste the compiler specific code into druntime. This works, as when the compiler is updated, so is the compiler-specific portion of druntime and nothing gets out of sync. Of course, a lot of druntime isn't compiler specific, for these parts patches should probably be applied. I'm not entirely sure where gdc and ldc are with respect to this kind of patch, I know they both have complete druntime implementations, but I'm sure if this kind of patch was made (preferably in smaller, individual patches for each feature/bug etc) it would be applied. Of course, this is just the situation as I see it, and from memory, the druntime folk will probably chime in and give the full story. Personally, I'd like to see one common runtime, but to achieve that requires that the compiler/runtime interface be essentially the same between the compilers. That's an achievable goal, but it has to actually be an agreed upon goal. Today, both gdc and ldc's interface with the runtime don't match dmd's. So, where do they differ today? Why? Can they evolve to a common interface? I'll happily apply patches from anyone providing them that work to achieve that goal. Please use bugzilla to submit them. One implied part of this goal is that dmd is, while an important stake holder, needs to play nice too. Changes need to go through a discussion round before being made.. no unilateral changes. Also, this discussion should probably drift over to the d-runt...@puremagic.com mailing list.. at least the parts that are directly related to accomplishing the changes. My 2 cents, Brad I'm not sure where to find / subscribe to the mailing list, so I posted here: http://d.puremagic.com/issues/show_bug.cgi?id=5478 Regards. For some reason it's not listed on the Digitalmars site with the rest of the mailing lists but here's the address: http://lists.puremagic.com/mailman/listinfo/d-runtime -- /Jacob Carlborg
Re: Opt-out closures
On 2011-01-23 16:08, bearophile wrote:
Sean Eskapp:
I want to be able to access the enclosing scope, but NOT after the function has
exited; I should have the option of accessing the enclosing scope, but at the
cost
of making my delegate not a closure.
It seems a worth thing to ask for. A possible syntax (not currently supported):
void foo() {
scope void bar() {}
}
Bye,
bearophile
Doesn't D2 have scoped delegates, at last as a parameter to a function?
--
/Jacob Carlborg
Re: Can your programming language do this?
"Adam D. Ruppe" wrote in message
news:ihhsv0$1fgf$1...@digitalmars.com...
> alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User;
> // sql source code , table to fetch
>
> void main() {
>auto obj = new User(null); // that null should actually be a db handle
> if
> you want to be able to commit changes
>
>// read/write access to the user table, with compile time
>// type and name checks
>
>obj.first = "Changing my name!";
>obj.date_last_edited = getUTCtime();
>
>obj.commitChanges(); // save your writes back to the database,
> (reasonably) efficiently
> }
>
>
>
> D can! It can dynamically make those DataObjects too, with the
> same syntax, but you lose compile time checks for obvious reasons.
>
>
> I just couldn't help but laugh a bit when I ran this thing through
> CTFE and found it actually worked, so figured I'd share a positive
> message with you guys :-)
>
> See my code here:
>
> http://arsdnet.net/dcode/database.d
>
> You might want a database implementation to play with too:
>
> http://arsdnet.net/dcode/mysql.d (best for this purpose so far)
> http://arsdnet.net/dcode/sqlite.d (but the others work too)
> http://arsdnet.net/dcode/postgres.d
>
> A simple db.sql file is here:
> http://arsdnet.net/dcode/db.sql
>
> It's just a list of CREATE TABLE commands. I ran the program over
> a far more complex file too and it worked, but it isn't a super
> smart parser so you can probably break it pretty easily. (for one,
> it is case sensitive where as standard SQL is not)
Sweet! I'd thought about doing something like that before, but frankly I'm
glad someone beat me to it :)
Re: Can your programming language do this?
Simen kjaeraas wrote: > I've known that D could do it, and I've occasionally > poked at it myself, but always felt it was too much work for > something that isn't all that hard to do by hand. Yeah, that's the way I feel about it mostly. What finally pushed me over the edge here was writing yet /another/ duplicated chunk of code for UPDATE and INSERT. Easy to do, but, ugh, so tedious!
Re: Opt-out closures hack
== Quote from Torarin (torar...@gmail.com)'s article
> 2011/1/23 Sean Eskapp :
> > I want to be able to access the enclosing scope, but NOT after the function
> > has
> > exited; I should have the option of accessing the enclosing scope, but at
> > the cost
> > of making my delegate not a closure.
> >
> Until we have a dedicated syntax for it, I think you can use this hack:
> import std.traits;
> auto scopeDelegate(D)(scope D d) if (isDelegate!D)
> {
> return d;
> }
> int main()
> {
>StructWithDtor s;
>trustedFunction(scopeDelegate({s.a = 5;}); // No heap allocation
> }
> Torarin
Yup, works great with everything I've tried! Thanks.
Re: druntime !!!!
== Quote from Brad Roberts (bra...@puremagic.com)'s article > On 1/23/2011 9:56 AM, Iain Buclaw wrote: > > == Quote from Brad Roberts (bra...@puremagic.com)'s article > >> On 1/22/2011 4:32 PM, Robert Clipsham wrote: > >>> On 22/01/11 23:58, bioinfornatics wrote: > They are something wrong with druntime management!!! > Why druntime do not support gdc or ldc2? > Its is very crap thing i hope druntime will add soon gdc support. We can > > send > ldc and gdc patch. > Thanks for all > > best regards > >>> > >>> I've been talking to you on IRC about this, but I'll reiterate it here for > >>> everyone elses benefit. Having support for each compiler in druntime is a bad > >>> idea. This is what druntime did initially when it was forked from tango. The > >>> trouble was that as the compiler got updated, the runtime needed to be > > updated > >>> too, and the compiler and runtime became out of sync very easily, and getting > >>> everything up to date again was a pain. > >>> > >>> The solution to this is to have each compiler maintain its own druntime > >>> compiler-specifics, and have the non-compiler-specific code in a main > > druntime > >>> repository - this way all that is needed is to copy/paste the compiler > > specific > >>> code into druntime. This works, as when the compiler is updated, so is the > >>> compiler-specific portion of druntime and nothing gets out of sync. > >>> > >>> Of course, a lot of druntime isn't compiler specific, for these parts patches > >>> should probably be applied. I'm not entirely sure where gdc and ldc are with > >>> respect to this kind of patch, I know they both have complete druntime > >>> implementations, but I'm sure if this kind of patch was made (preferably > >>> in > >>> smaller, individual patches for each feature/bug etc) it would be applied. > >>> > >>> Of course, this is just the situation as I see it, and from memory, the > > druntime > >>> folk will probably chime in and give the full story. > >>> > >> Personally, I'd like to see one common runtime, but to achieve that > >> requires > >> that the compiler/runtime interface be essentially the same between the > >> compilers. That's an achievable goal, but it has to actually be an agreed upon > >> goal. Today, both gdc and ldc's interface with the runtime don't match dmd's. > >> So, where do they differ today? Why? Can they evolve to a common interface? > >> I'll happily apply patches from anyone providing them that work to achieve that > >> goal. Please use bugzilla to submit them. > >> One implied part of this goal is that dmd is, while an important stake holder, > >> needs to play nice too. Changes need to go through a discussion round before > >> being made.. no unilateral changes. > >> Also, this discussion should probably drift over to the d- runt...@puremagic.com > >> mailing list.. at least the parts that are directly related to > >> accomplishing > > the > >> changes. > >> My 2 cents, > >> Brad > > > > I'm not sure where to find / subscribe to the mailing list, so I posted > > here: > > http://d.puremagic.com/issues/show_bug.cgi?id=5478 > > > > Regards. > Lists: http://lists.puremagic.com OK, thanks. I'll get signed up there. > I like the summary of problems, I dislike that it's more than one report per > bug. It makes dealing with them a royal pain. One issue per bug please. It's a follow-on from the report Thomas made back in 2007, as DMD's library calls have changed since. GDC haven't changed at all with the exception of one or two additions to the list for D2. Regards
Re: question: prefer SSE over x87 asm code?
Note that SSE is less precise than x87.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Dmitry Olshansky wrote: If the D becomes common used language we can "examine" its new features and take in into consideration. But... Maybe is's easier to contact with D developer and ask for new features in objects. If the author wants to email me with any specific questions, I'd be happy to help him.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
On 23.01.2011 23:55, Walter Bright wrote: Dmitry Olshansky wrote: If the D becomes common used language we can "examine" its new features and take in into consideration. But... Maybe is's easier to contact with D developer and ask for new features in objects. If the author wants to email me with any specific questions, I'd be happy to help him. Yeah, that's the problem, I suppose he would not bother with D support himself unless someone proves it's usefulness. It's more like we need a little help not the other way around. Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? May I just as well tell him that you are interested in it or anything? -- Dmitry Olshansky
Re: Is it true scope declarations are being removed?
Sadly true. They intend to replace it with a library based solution, I don't know why.
Re: Is it true scope declarations are being removed?
I don't understand it either. AFAIK they are being removed because they're unsafe, and are being replaced by an unsafe library solution.
Re: Is it true scope declarations are being removed?
Andrej Mitrovic: > I don't understand it either. AFAIK they are being removed because > they're unsafe, and are being replaced by an unsafe library solution. I have hated see typedef and scoped classes go (I have even missed delete), but you need a bit of faith in the future and in Andrei & Walter. Andrei is not evil, and he's smart. D2 language is a very young language, and when a built-in feature looks not perfect, it's better to remove it now. If you remove it, you will have plenty of time in future to add it back, add something better implementation of it, or to find a better and very different solution, or even to add a more general language feature that allows you to implement the original half-broken feature in library code. While if something badly designed is left in the language, then you are struck with it forever, or almost forever. Generally in language it's 10-100 times simpler to add a new feature than to remove it :-) Better to start with a not complete D2 language, a language with holes waiting to be filled, that with a language with unfixable warts that you may "fix" just adding another better feature and preten! ding the old one doesn't exist any more (example: nullptr of C++0x). Bye, bearophile
Re: Is it true scope declarations are being removed?
I don't understand it either. AFAIK they are being removed because they're unsafe, and are being replaced by an unsafe library solution. I have the same feeling. While I do understand why typedef is poorly designed (http://d.puremagic.com/issues/show_bug.cgi?id=5467) I can't imagine how a library-based scope is any better than before.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Hopefully we can get the author to support dmd. I can't wait years until optlink might support x64.
Re: Is it true scope declarations are being removed?
On Mon, 24 Jan 2011 00:11:48 +0200, Trass3r wrote: Sadly true. They intend to replace it with a library based solution, I don't know why. If the library solution is as good as the original, it is a big plus. If only we could do the same for everything!
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Dmitry Olshansky wrote: On 23.01.2011 23:55, Walter Bright wrote: Dmitry Olshansky wrote: If the D becomes common used language we can "examine" its new features and take in into consideration. But... Maybe is's easier to contact with D developer and ask for new features in objects. If the author wants to email me with any specific questions, I'd be happy to help him. Yeah, that's the problem, I suppose he would not bother with D support himself unless someone proves it's usefulness. It's more like we need a little help not the other way around. Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? May I just as well tell him that you are interested in it or anything? First off, there are no D extensions to the OMF. There was an extension added around 1993 or so to support long identifier names. There were also a couple extensions to the codeview debug format, which are documented in the ABI. My offer is if there is something specific about the OMF files generated that I can explain to him, I'd be happy to do so. My mail is walter followed by digitalmars.com.
Re: Is it true scope declarations are being removed?
On Friday 21 January 2011 06:10:26 Sean Eskapp wrote:
> Someone mentioned to me that scope declarations, e.g.
>
> scope class A{}
> or
> scope A myNewObject;
>
> are being removed from the language. Is this true? If so, how will
> RAII-type classes be implemented?
std.typecons.scoped is the replacement for the builtin scope declaration. scope
declarations are going away because they're inherently unsafe. Why they are
then
being put into the library, I'm not quite sure, other than the fact that D
doesn't _stop_ you from doing unsafe stuff, it just seriously discourages it. I
suppose that the big problem with having it in the language itself that the
library solution doesn't quite have is that having it in the language kind of
implies that it's okay and reasonable to do, which it isn't. It makes sense in
specific circumstances, where you're know what all of the code involved is
doing
and can be sure that no reference to the scoped class will escape. And even
then, why didn't you just make it a struct in the first place? There _are_ uses
for scoped classes, but they're really not supposed to be the norm. They're
unsafe, and you're begging for bugs if you use them heavily.
- Jonathan M Davis
Re: druntime !!!!
bioinfornatics Wrote: > They are something wrong with druntime management!!! > Why druntime do not support gdc or ldc2? Should it? Even if the devlopers of GDC and LDC2 were interested (and neither have contacted me indicating this), I'm not sure it's an optimal workflow to have all compiler runtimes hosted out of the same repository. I did this for Tango by necessity and it was a major pain.
first git commit
We've moved the entire camp to github: dmd compiler, phobos, druntime, website, installer. I'm happy to report that we have our first git commit: https://github.com/D-Programming-Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 Andrei
Re: first git commit
I like the new diff. Although there doesn't seem to be syntax highlighting (or is that usual for diffs?). Anyway, congrats!
Re: first git commit
Andrei Alexandrescu Wrote: > We've moved the entire camp to github: dmd compiler, phobos, druntime, > website, installer. > > I'm happy to report that we have our first git commit: > > https://github.com/D-Programming-Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 > > > Andrei > I've moved my team at work to git more than two years ago and it improved work-flow and speed of development by a few orders of magnitude. Based on my experience with git, this is a huge step forward for D development. Congratulations.
Re: first git commit
On Sun, Jan 23, 2011 at 10:14 PM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > We've moved the entire camp to github: dmd compiler, phobos, druntime, > website, installer. > > I'm happy to report that we have our first git commit: > > > https://github.com/D-Programming-Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 > > > Andrei > > What about the GDC team? Are they planning to switch to Git as well?
