protractor glyph recognizer
Hello. here i presenting to you simple, but working ProTractor[1] glyph recognizer. it is a successor of $1 gesture recognizer[2]. it's reasonably reliable and fast. http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/geng.d i don't think that you really need any documentation for it, as everything is very simple. the only thing you have to remember is that you'd better keep all template glyphs normalized. here is some quickhack sample using my other IV modules: http://repo.or.cz/w/iv.d.git/tree/HEAD:/protractor_test i included simple glyph reader and writer, so you can easily store and load your glyph libraries. [1] http://yangl.org/pdf/protractor-chi2010.pdf [2] http://depts.washington.edu/aimgroup/proj/dollar/ signature.asc Description: PGP signature
Re: Do everything in Java…
On Saturday, 6 December 2014 at 01:53:03 UTC, Rikki Cattermole wrote: On 6/12/2014 5:45 a.m., Dicebot wrote: In my opinion OOP is very unfriendly for testing as a paradigm in general. The very necessity to create mocks is usually an alarm. I really need to start saving quotes. This is definitely a keeper! Except that in procedural code that option doesn't even exist, so no testing without going to the network.
Re: Help with d_language subreddit on Reddit
On Friday, 5 December 2014 at 23:25:11 UTC, Walter Bright wrote: https://www.reddit.com/r/d_language/ It's the default, and is kinda boring. Compare with the rust subreddit: http://www.reddit.com/r/rust/ While not great, it's much better than ours. Being a moderator, I can change the look/feel of it by modifying the CSS: https://www.reddit.com/wiki/styling But, as you all have pointed out to me innummerable times, I have no taste in styling. So anyone want to give me a hand? Also, so far I haven't figured out how to change the sidebar, which would be nice to insert links to dlang.org, etc., into. I feel ashamed, i didn't even know this subreddit existed.
Re: Do everything in Java…
On 12/5/2014 11:54 PM, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote: Code review my friend. Nothing gets in without review, and as won't usually don't enjoy the prospect of having to fix the shit of a coworker, one ensure that coworker wrote proper tests. Good luck making that work in companies. Code review is something for open source projects and agile conferences. I've worked at several companies, both large and gigantic, and it's worked very well at all of them. Code reviews are an important part of healthy and quality code development processes.
Re: Do everything in Java…
On Sat, 06 Dec 2014 07:54:32 + Paulo Pinto via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote: On Friday, 5 December 2014 at 20:43:03 UTC, paulo pinto wrote: On Friday, 5 December 2014 at 20:25:49 UTC, Walter Bright wrote: On 12/5/2014 1:27 AM, Paulo Pinto wrote: Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. I write unit tests with the goal of exercising every line of code. While one can argue that that doesn't really test what the code is supposed to be doing, my experience is that high coverage percentages strongly correlate with few problems down the road. I imagine you haven't seen unit tests written by off-shore contractors For example, you can have coverage without asserts. Code review my friend. Nothing gets in without review, and as won't usually don't enjoy the prospect of having to fix the shit of a coworker, one ensure that coworker wrote proper tests. Good luck making that work in companies. Code review is something for open source projects and agile conferences. hm. i should tell my mates that our company with 100+ employers from several countries is doing something wrong, as no code can be commited here without review... signature.asc Description: PGP signature
Re: D Meetup in Berlin
Nice! I will have to see if I can make it. BTW. is sociomantic still hiring ?
Re: Do everything in Java…
On Saturday, 6 December 2014 at 08:36:28 UTC, ketmar via Digitalmars-d wrote: On Sat, 06 Dec 2014 07:54:32 + Paulo Pinto via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote: On Friday, 5 December 2014 at 20:43:03 UTC, paulo pinto wrote: On Friday, 5 December 2014 at 20:25:49 UTC, Walter Bright wrote: On 12/5/2014 1:27 AM, Paulo Pinto wrote: Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. I write unit tests with the goal of exercising every line of code. While one can argue that that doesn't really test what the code is supposed to be doing, my experience is that high coverage percentages strongly correlate with few problems down the road. I imagine you haven't seen unit tests written by off-shore contractors For example, you can have coverage without asserts. Code review my friend. Nothing gets in without review, and as won't usually don't enjoy the prospect of having to fix the shit of a coworker, one ensure that coworker wrote proper tests. Good luck making that work in companies. Code review is something for open source projects and agile conferences. hm. i should tell my mates that our company with 100+ employers from several countries is doing something wrong, as no code can be commited here without review... I can count with one hand the companies I have witness doing it. -- Paulo
Re: Do everything in Java…
On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via Digitalmars-d wrote: On 12/5/2014 11:54 PM, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote: Code review my friend. Nothing gets in without review, and as won't usually don't enjoy the prospect of having to fix the shit of a coworker, one ensure that coworker wrote proper tests. Good luck making that work in companies. Code review is something for open source projects and agile conferences. I've worked at several companies, both large and gigantic, and it's worked very well at all of them. Code reviews are an important part of healthy and quality code development processes. Maybe I have worked at wrong companies then. In 20 years of career I can count with one hand those that did it, and most developers hated it. Never lasted more than a few meetings. -- Paulo
Re: Do everything in Java…
Unittests are great to avoid regressions. Unitests give confidence. You can do radical changes to your codebase much easier if you know, that nothing breaks because of it. I not a fan of TDD. But I like it that I know directly that there are no regressions.
Re: Do everything in Java…
06-Dec-2014 01:28, Freddy пишет: On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on. http://www.teamten.com/lawrence/writings/java-for-everything.html My problems with java: no unsigned ints primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) no operator overloading(looks at java.util.ArrayList) no templates no property syntax(getters and setters are used instead even if you know the field is never going to be dynamic) only and exactly one class per file(ALL THE IMPORTS) every thing must be inside a class(globals and free functions are static fields in a class) This is all i can remember. Solved in Scala: - operator overloading - properties - that + optional (), a library writer still can enforce () to be used - only and exactly one class - any number in any combination - everything class - sort of, it has 'object' clause (just like 'class') that can be thought as a kind of namespace or a singleton if you love OOP. Not fixed: - unsigend types - nothing here unless Java adds support - pasing by value - there are immutable and value types (e.g. Tuples) but I think they are references behind the scenes - no templates, but you may use AST macros which is even more powerful -- Dmitry Olshansky
Re: D Meetup in SF?
On 2014-12-05 20:08:28 +, Vic said: http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there. I was thinking of something in SF proper, but Sunnyvale may be possible for me. -S
Re: Do everything in Java…
On 12/5/2014 10:12 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 04:49:02AM +0200, ketmar via Digitalmars-d wrote: On Fri, 05 Dec 2014 02:39:49 + deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: [...] Also relevant: http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application i didn't make it past the contents. too hard for silly me. Whoa. Thanks for the link -- I was actually at some point considering maybe to get into the Java field instead of being stuck with C/C++ at work, but after reading that page, I was completely dispelled of the notion. I think I would lose my sanity after 5 minutes of clicking through those endless submenus, typing out XML by hand (argh), and writing 50 pages of Java legalese and setting up 17 pieces of scaffolding just to get a Hello World program to run. Whoa! I think I need therapy just skimming over that page. This is sooo over-engineered it's not even funny. For all their flaws, C/C++ at least doesn't require that level of inanity... I really don't think a Hello World example is representative of the usefulness of Java in the web. I don't see it as being over-engineered at at all (though that is a disease Java programmers are often afflicted with). The XML configuration allows you to be portable across web containers and application servers, while using only the bits of the JEE specification that you need. Anyone doing serious Java web dev, from servlets to full-blown JEE stacks, is going to be using a Java IDE that generates much of what is needed anyway, and will only need to tweak the config files for customization. I've done Java backends on a contract basis in the past. If I needed to whip up a web app today, I'd still choose Java.
Re: Do everything in Java...
On Friday, 5 December 2014 at 21:21:49 UTC, Ola Fosheim Grøstad wrote: On Friday, 5 December 2014 at 20:32:54 UTC, H. S. Teoh via Digitalmars-d wrote: I agree. It's not just about conservation of resources and power, though. It's also about maximizing the utility of our assets and extending our reach. If I were a business and I invested $10,000 in servers, wouldn't I want to maximize the amount of computation I can get from these servers before I need to shell out money for more servers? Those $10,000 in servers is a small investment compared to the cost of the inhouse IT department to run them… Which is why the cloud make sense. Why have all that unused capacity inhouse (say 90% idle over 24/7) and pay someone to make it work, when you can put it in the cloud where you get load balancing, have a 99,999% stable environment and can cut down on the IT staff? There are also certain large computational problems that basically need every last drop of juice you can get in order to have any fighting chance to solve them. Sure, but then you should run it on SIMD processors (GPUs) anyway. And if you only run a couple of times a month, it still makes sense to run it on more servers using map-reduce in the cloud where you only pay for CPU time. The only situation where you truly need dedicated servers is where you have real time requirements, a constant high load or where you need a lot of RAM because you cannot partition the dataset. Big simulations still benefit from dedicated clusters. Good performance often requires uniformly extremely low latencies between nodes, as well as the very fastest in distributed storage (read *and* write). P.S. GPUs are not a panacea for all hpc problems. For example, rdma is only a recent thing for GPUs across different nodes. In general there is a communication bandwidth and latency issue: the more power you pack in each compute unit (GPU or CPU or whatever), the more bandwidth you need connecting them.
Re: Do everything in Java…
On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote: 06-Dec-2014 01:28, Freddy пишет: On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on. http://www.teamten.com/lawrence/writings/java-for-everything.html My problems with java: no unsigned ints primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) no operator overloading(looks at java.util.ArrayList) no templates no property syntax(getters and setters are used instead even if you know the field is never going to be dynamic) only and exactly one class per file(ALL THE IMPORTS) every thing must be inside a class(globals and free functions are static fields in a class) This is all i can remember. Solved in Scala: - operator overloading - properties - that + optional (), a library writer still can enforce () to be used - only and exactly one class - any number in any combination - everything class - sort of, it has 'object' clause (just like 'class') that can be thought as a kind of namespace or a singleton if you love OOP. Not fixed: - unsigend types - nothing here unless Java adds support - pasing by value - there are immutable and value types (e.g. Tuples) but I think they are references behind the scenes - no templates, but you may use AST macros which is even more powerful Some form of unsigned arithmetic exists since Java 8. For example, https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedInt-byte- https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#remainderUnsigned-int-int- There many more methods available.
Re: DIP69 - Implement scope for escape proof references
On 6 December 2014 at 09:58, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12/5/2014 8:48 AM, Marc Schütz schue...@gmx.net wrote:
There are limitations this proposal has in comparison to my original one.
These
limitations might of course be harmless and play no role in practice, but
on the
other hand, they may, so I think it's good to list them here.
Good idea. Certainly, this is less powerful than your proposal. The
question, obviously, is what is good enough to get the job done. By the
job, I mean reference counting, migrating many allocations to RAII (meaning
the stack), and eliminating a lot of closure GC allocations.
Additionally I have to agree with Steven Schveighoffer: This DIP is very
complicated to understand. It's not obvious how the various parts play
together,
and why/to which degree it works, and which are the limitations. I don't
think
that's only because my brain is already locked on my proposal...
I'm still looking for an easier way to explain it. The good news in this,
however, is if it is correctly implement the compiler should be a big help
in using scope correctly.
1) Escape detection is limited to `ref`.
T* evil;
ref T func(scope ref T t, ref T u) @safe {
return t; // Error: escaping scope ref t
return u; // ok
evil = u; // Error: escaping reference
}
vs.
T[] evil;
T[] func(scope T[] t, T[] u) @safe {
return t; // Error: cannot return scope
return u; // ok
evil = u; // !!! not good
right, although:
evil = t; // Error: not allowed
}
As can be seen, `ref T u` is protected from escaping (apart from returning
it),
while `T[] u` in the second example is not. There's no general way to
express
that `u` can only be returned from the function, but will not be retained
otherwise by storing it in a global variable. Adding `pure` can express
this in
many cases, but is, of course, not always possible.
As you point out, 'ref' is designed for this.
Another workaround is passing the parameters as `ref`, but this would
introduce
an additional indirection and has different semantics (e.g. when the
lengths of
the slices are modified).
2) `scope ref` return values cannot be stored.
scope ref int foo();
void bar(scope ref int a);
foo().bar();// allowed
scope tmp = foo(); // not allowed
tmp.bar();
Right
Another example:
struct Container(T) {
scope ref T opIndex(size_t index);
}
void bar(scope ref int a);
Container c;
bar(c[42]);// ok
scope ref tmp = c[42]; // nope
Both cases should be fine theoretically; the real owner lives longer
than
`tmp`. Unfortunately the compiler doesn't know about this.
Right, though the compiler can optimize to produce the equivalent.
Both restrictions 1) and 2) are because there are no explicit
lifetime/owner
designations (the scope!identifier thingy in my proposal).
3) `scope` cannot be used for value types.
I can think of a few use cases for scoped value types (RC and file
descriptors),
but they might only be marginal.
I suspect that one can encapsulate such values in a struct where access to
them is strictly controlled.
4) No overloading on `scope`.
This is at least partially a consequence of `scope` inference. I think
overloading can be made to work in the presence of inference, but I
haven't
thought it through.
Right. Different overloads can have different semantic implementations, so
what should inference do? I also suspect it is bad style to overload on
'scope'.
5) `scope` is a storage class.
Manu complained about `ref` being a storage class. If I understand him
right,
one reason is that we have a large toolkit for dealing with type
modifiers, but
almost nothing for storage classes. I have to agree with him there. But I
haven't understood his point fully, maybe he himself can post more about
his
problems with this?
I didn't fully understand Manu's issue, but it was about 'ref' not being
inferred by template type deduction. I didn't understand why 'auto ref' did
not work for him. I got the impression that he was trying to program in D
the same way he'd do things in C++, and that's where the trouble came in.
NO!!
I barely program C++ at all! I basically write C code with 'enum' and
'class'. NEVER 'template', and very rarely 'virtual'.
Your impression is dead wrong.
If I do things in any particular 'way', it is that at all times, I
have regard for, and control over the code generation, the ABI, and I
also value distribution of code as static libs, which means I must
retain tight control over where code is, and isn't, emitted.
I expect this from a native language.
It's exactly as Marc says, we have the best tools for dealing with
types of any language I know, and practically none for dealing with
'storage class'.
In my use of meta in D, 'ref' is
Re: DIP69 - Implement scope for escape proof references
On Friday, 5 December 2014 at 16:48:45 UTC, Marc Schütz wrote: There are limitations this proposal has in comparison to my original one. These limitations might of course be harmless and play no role in practice, but on the other hand, they may, so I think it's good to list them here. One concern I had with your proposal was that it refers to a symbol before it's available. scope!haystack(string) findSubstring(scope(string) haystack, scope(string) needle) C++11 had similar issues and they solved it by introducing trailing return types. ex: templateclass T auto mul(T a, T b) - decltype(a*b) Personally I would prefer not to go down that lane and DIP69 avoids that problem.
Re: DIP69 - Implement scope for escape proof references
On 2014-12-06 10:50, Manu via Digitalmars-d wrote: I've been over it so many times. I suggest you take the time and write down how your vision of ref looks like and the issue with the current implementation. A blog post, a DIP or similar. Then you can easily refer to that in cases like this. Then you don't have to repeat yourself so many times. That's what I did when there was a lot of talk about AST macros. I was tired of constantly repeating myself so I created a DIP. It has already saved me more time than it took to write the actual DIP. -- /Jacob Carlborg
Re: Do everything in Java?
On Friday, 5 December 2014 at 23:09:56 UTC, deadalnix wrote: Go is more mature than D. They have at least 2 implementation and well fleshed out specs. Granted, it is easier in Go as the language is smaller. Yes, the Go feature set is relative mature and they have stable releases, but Google has advertisers as their customers so they can drop tools any time the feel like with no effect on customers. Chrome, Dart and PNaCl is all about securing Google Search, providing tools for developers is a by product… I don't trust Google until they commit to making Go available as a supported tool to customers that they make revenue from. Google will probably evolve Go until it fits their own needs, but once they make it available as a supported tool on AppEngine they will have to commit to maintaining it as a stable release. It does say something that it has been in experimental/beta state for years on AppEngine. At Cppcon representatives from Google clearly stated that they could not see Go replace C++ any time soon. Overall that sounds like Google internally does not view Go as complete even though the Go authors think it is…
Re: Do everything in Java...
On Saturday, 6 December 2014 at 09:24:57 UTC, John Colvin wrote: Big simulations still benefit from dedicated clusters. Good performance often requires uniformly extremely low latencies between nodes, as well as the very fastest in distributed storage (read *and* write). The question is not performance between nodes if you can partition the dataset (which I made a requirement), but how much you pay in total for getting the job done. So you can have inefficiency and still profit by renting CPU time because the total cost of ownership from having a local under-utilized server farm can be quite high. But if the simulation requires a NUMA-like architecture… then you don't have a dataset that you can partition and solve in a map-reduce style. P.S. GPUs are not a panacea for all hpc problems. For example, rdma is only a recent thing for GPUs across different nodes. In general there is a communication bandwidth and latency issue: the more power you pack in each compute unit (GPU or CPU or whatever), the more bandwidth you need connecting them. HPC is a special case and different architectures will suit different problems, so you have to tailor the hardware architecture to the problems you want to solve, but then we are not talking $10.000 servers… If you need RDMA, then you are basically in NUMA land, which is not really suitable for a generic cloud solution in the first place?
Re: Do everything in Java...
On Saturday, 6 December 2014 at 12:04:48 UTC, Ola Fosheim Grøstad wrote: not talking $10.000 servers… If you need RDMA, then you are basically in NUMA land, which is not really suitable for a generic cloud solution in the first place? Actually, Microsoft Azure provides InfiniBand RDMA for 4.47USD/hour for their A8 and A9 nodes: http://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux
Re: DIP69 - Implement scope for escape proof references
On Saturday, 6 December 2014 at 04:31:48 UTC, Sebastiaan Koppe wrote: What about also adding the inverse of scope? Then scope can be inferred. As in: ``` void foo(int* p); void free(P)(consume P* p); Yes, this is much better. When I suggested it, it was rejected because D is too concerned about breaking existing code. Which is a not-very-good argument since this breaking change is concervative (you only have to add consume or something similar when the compiler complains). The obvious solution is to do as you suggest and in addition do all @safe analysis on a high level IR layer using dataflow through and through. Instead D continues down the rather flimsy path of partially addressing these issues in the type system… which will lead to a more complicated and less complete solution where @safe basically continues to be a leaky cauldron…
Re: DIP69 - Implement scope for escape proof references
On Saturday, 6 December 2014 at 10:59:24 UTC, Daniel N wrote: On Friday, 5 December 2014 at 16:48:45 UTC, Marc Schütz wrote: There are limitations this proposal has in comparison to my original one. These limitations might of course be harmless and play no role in practice, but on the other hand, they may, so I think it's good to list them here. One concern I had with your proposal was that it refers to a symbol before it's available. scope!haystack(string) findSubstring(scope(string) haystack, scope(string) needle) C++11 had similar issues and they solved it by introducing trailing return types. ex: templateclass T auto mul(T a, T b) - decltype(a*b) Personally I would prefer not to go down that lane and DIP69 avoids that problem. For D, this wouldn't be necessary, because parsing and semantic analysis are strictly separated. The owners would only have to be evaluated very late during the semantic phase. But let's see how DIP69 works out...
Re: DIP69 - Implement scope for escape proof references
On 04/12/2014 21:23, H. S. Teoh via Digitalmars-d wrote:
@property scope ref T borrow() { return t; }
alias borrow this;
While this DIP enabling the above to be memory-safe is awesome, a later
tweak to AliasThis grammar to allow storage classes could make 'borrow'
redundant. Plain alias now allows storage classes:
AliasDeclaration:
alias StorageClassesopt BasicType Declarator ;
So:
TweakedAliasThis:
alias StorageClassesopt Identifier this ;
Given ref and now scope will be storage classes, that would then allow just:
alias scope ref t this;
Re: DIP69 - Implement scope for escape proof references
On Friday, 5 December 2014 at 23:58:41 UTC, Walter Bright wrote:
On 12/5/2014 8:48 AM, Marc Schütz schue...@gmx.net wrote:
1) Escape detection is limited to `ref`.
T* evil;
ref T func(scope ref T t, ref T u) @safe {
return t; // Error: escaping scope ref t
return u; // ok
evil = u; // Error: escaping reference
}
vs.
T[] evil;
T[] func(scope T[] t, T[] u) @safe {
return t; // Error: cannot return scope
return u; // ok
evil = u; // !!! not good
right, although:
evil = t; // Error: not allowed
}
As can be seen, `ref T u` is protected from escaping (apart
from returning it),
while `T[] u` in the second example is not. There's no general
way to express
that `u` can only be returned from the function, but will not
be retained
otherwise by storing it in a global variable. Adding `pure`
can express this in
many cases, but is, of course, not always possible.
As you point out, 'ref' is designed for this.
I wouldn't call it designed, but repurposed...
struct Container(T) {
scope ref T opIndex(size_t index);
}
void bar(scope ref int a);
Container c;
bar(c[42]);// ok
scope ref tmp = c[42]; // nope
Both cases should be fine theoretically; the real owner
lives longer than
`tmp`. Unfortunately the compiler doesn't know about this.
Right, though the compiler can optimize to produce the
equivalent.
??? This is a problem on the semantic level, unrelated to
optimization:
// contrived example to illustrated the point
Container c;
scope ref x = c[42]; // not
scope ref y = c[44]; // ...
scope ref z = c[13]; // allowed
foo(x, y, z, x+y, y+z, z+x, x+y+z);
// workaround, but error-prone and has different semantics
// (opIndex may have side effects, called multiple times)
foo(c[42], c[44], c[13], c[42]+c[44], c[44]+c[13],
c[13]+c[42], c[42]+c[44]+c[13]);
// another workaround, same semantics, but ugly and unreadable
(scope ref int x, scope ref int y, scope ref int z) {
foo(x, y, z, x+y, y+z, z+x, x+y+z);
}(c[42], c[44], c[13]);
3) `scope` cannot be used for value types.
I can think of a few use cases for scoped value types (RC and
file descriptors),
but they might only be marginal.
I suspect that one can encapsulate such values in a struct
where access to them is strictly controlled.
They can, but again at the cost of an indirection (ref).
4) No overloading on `scope`.
This is at least partially a consequence of `scope` inference.
I think
overloading can be made to work in the presence of inference,
but I haven't
thought it through.
Right. Different overloads can have different semantic
implementations, so what should inference do? I also suspect it
is bad style to overload on 'scope'.
It only makes sense with scope value types (see the RC example).
For references, I don't know any useful applications.
6) There seem to be problems with chaining.
scope ref int foo();
scope ref int bar1(ref int a) {
return a;
}
scope ref int bar2(scope ref int a) {
return a;
}
ref int bar3(ref int a) {
return a;
}
ref int bar4(scope ref int a) {
return a;
}
void baz(scope ref int a);
Which of the following calls would work?
foo().bar1().baz();
yes
foo().bar2().baz();
no - cannot return scope ref parameter
foo().bar3().baz();
yes
foo().bar4().baz();
no, cannot return scope ref parameter
I'm not sure I understand this fully yet, but it could be that
none of them work...
Well, you're half right :-)
Ok, so let's drop bar2() and bar4().
scope ref int foo();
scope ref int bar1(ref int a) {
return a;
}
ref int bar3(ref int a) {
return a;
}
ref int baz_noscope(/*scope*/ ref int a);
foo().bar1().baz_noscope();
foo().bar3().baz_noscope();
And now? In particular, will the return value of `bar3` be
treated as if it were `scope ref`?
Re: DIP69 - Implement scope for escape proof references
On Saturday, 6 December 2014 at 09:51:15 UTC, Manu via Digitalmars-d wrote: I've been over it so many times. I'll start over if there is actually some possibility I can convince you? Is there? I've lost faith that I am able to have any meaningful impact on issues that matter to me, and I'm fairly sure at this point that my compounded resentment and frustration actually discredit my cause, and certainly, my quality of debate. I'm passionate about these things, but I'm also extremely frustrated. To date, whenever I have engaged in a topic that I *really* care about, it goes the other direction. To participate has proven to be something of a (very time consuming) act of masochism. That's very sad to hear. I think you have brought up some very important points, especially from a practical point of view. I __absolutely objected__ to 'auro ref' when it appeared. I argued that it was a massive mistake, and since it's introduction and experience with it in the wild, I am more confident in that conviction than ever. As a programmer, I expect control over whether code is a template, or not. 'ref' doesn't have anything to do with templates. Confusing these 2 concepts was such a big mistake. auto ref makes a template out of something that shouldn't be a template. It's a particularly crude hack to address a prior mistake. ref should have been fixed at that time, not compounded with layers of even more weird and special-case/non-uniform behaviours above it. There has been a couple of instances where the situation has been appropriate that I've tried to make use of auto ref, but in each case, the semantics have never been what I want. auto ref presumes to decide for you when something should be a ref or not. It prescribes a bunch of rules on how that decision is made, but it doesn't know what I'm doing, and it gets it wrong. In my experience, auto ref has proven to be, at best, completely useless. But in some cases I've found where I bump into it in 3rd party code, it's been a nuisance, requiring me to wrap it away. I tend to agree with this. Here's an example of the dangers: https://github.com/deadalnix/libd/pull/7 In this case, `auto ref` accepted a class by reference, because it chooses ref-ness based on whether you pass an lvalue or an rvalue. This is not very helpful. I agree that `ref` isn't something that should ever be inferred, because it affects the semantics of the function. Either the function requires `ref` semantics, or not. It doesn't depend on how it is called.
Re: DIP69 - Implement scope for escape proof references
Marc Schütz: I agree that `ref` isn't something that should ever be inferred, because it affects the semantics of the function. Either the function requires `ref` semantics, or not. It doesn't depend on how it is called. (Perhaps this was already said) I think Ada used to have something like auto ref and later it was removed from the language. Bye, bearophile
Re: D Meetup in SF?
On Saturday, 6 December 2014 at 01:37:03 UTC, deadalnix wrote: On Friday, 5 December 2014 at 20:08:30 UTC, Vic wrote: http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there. Is that new ? I was unaware of this. Not sure I'll be able to come as I have no car, but I'll try to figure out something. If you Cal-Train, we will pick up at station.
Re: D Meetup in SF?
On Saturday, 6 December 2014 at 09:12:30 UTC, Shammah Chancellor wrote: On 2014-12-05 20:08:28 +, Vic said: http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there. I was thinking of something in SF proper, but Sunnyvale may be possible for me. -S We can co-ordinate Caltrain schedule and have somoneone pick up at the train station.
Re: D Meetup in Berlin
On Saturday, 6 December 2014 at 08:41:22 UTC, Stefan Koch wrote: Nice! I will have to see if I can make it. BTW. is sociomantic still hiring ? https://www.sociomantic.com/jobs/d-software-developer/
Re: Do everything in Java…
On Fri, 2014-12-05 at 20:56 +, paulo pinto via Digitalmars-d wrote: […] I am yet to enconter any project using zeromq. […] Many of the financial institutions in London are using ZeroMQ for a lot of their projects. It does it's job very well. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Fri, 2014-12-05 at 12:44 -0800, Walter Bright via Digitalmars-d wrote: On 12/5/2014 5:41 AM, H. S. Teoh via Digitalmars-d wrote: As for GUI code, I've always been of the opinion that it should be coded in such a way as to be fully scriptable. GUI's that can only operate when given real user input has failed from the start IMO, because not being scriptable also means it's non-automatable (crippled, in my book), but more importantly, it's not auto- testable; you have to hire humans to sit all day repeating the same sequence of mouse clicks just to make sure the latest dev build is still working properly. That's grossly inefficient and a waste of money spent hiring the employee. You actually need both. Scripting end-to-end tests, systems tests, etc. is important but most systems also needs humans to try things out. A complementary approach is to have the UI code call semantic routines that are in non-UI code, and those semantic routines do all the semantic work. That minimizes the UI code, and hence the testing problem. The usual model is that GUI code only has GUI code and uses a Mediator and/or Façade to access any other code. Similarly separate business rules from database access (DAO, etc.). Separation of Concerns, Three Tier Model, MVC, MVP, there are masses of labels for the fundamental architecture, but it is all about modularization and testability. Most GUI apps I've seen mixed up all that code together. You haven't seen many then :-), and most of them have been crap and should have had the incantation rm -rf * applied. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Fri, 2014-12-05 at 12:59 -0800, H. S. Teoh via Digitalmars-d wrote: […] I had to implement a drag-n-drop function in Javascript once, and the thing was one big convoluted mess, even after excluding the semantic part (which in this case is trivial). It left me really longing to have some kind of unittest framework to verify that later code changes won't break that fragile tower of cards, but alas, we didn't have any such framework available. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, 2014-12-06 at 01:15 +, deadalnix via Digitalmars-d wrote: […] In my experience, having no QA actually works better. Another approach is to not have a QA department, but one or 2 QA guys within the dev team. There's a label for that: DevOps. Except that the term is rapidly loosing is proper meaning as people start using it without understanding what it used to mean. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 08:46:58AM +, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via Digitalmars-d wrote: On 12/5/2014 11:54 PM, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote: Code review my friend. Nothing gets in without review, and as won't usually don't enjoy the prospect of having to fix the shit of a coworker, one ensure that coworker wrote proper tests. Good luck making that work in companies. Code review is something for open source projects and agile conferences. I've worked at several companies, both large and gigantic, and it's worked very well at all of them. Code reviews are an important part of healthy and quality code development processes. Maybe I have worked at wrong companies then. In 20 years of career I can count with one hand those that did it, and most developers hated it. Never lasted more than a few meetings. [...] Huh, what...?? Meetings? For code review??? How does that even work...? Where I work, code review is done as part of the change committing process. No code gets merged into the mainline codebase without somebody reviewing it -- and recently they've upped the process to require 2 or more reviewers who approve the changes, both at the code level and at the higher feature level. These reviews are ongoing all the time -- you work on your code, test it locally, and once you're reasonably confident of it, you submit it to QA for further testing and sanity testing, then once that's approved, you submit it to your team lead and he reviews it, and if it has problems, he will reject it. If it gets approved, then it gets reviewed by a wider panel of reviewers drawn from teams who are responsible for the component(s) touched by the code change. Only when they OK the change, will it get merged into the mainline. However, all this level of review kinda loses a lot of its effectiveness because we have no unittesting system, so regressions are out of control. :-( The code is complex enough that even with all this review, things still slip through. The lack of automation also means QA tests are sometimes rather skimpy and miss obvious regressions. Having automated unittesting would go a long ways in improving this situation. T -- Живёшь только однажды.
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 03:11:01PM +, Russel Winder via Digitalmars-d wrote: On Fri, 2014-12-05 at 12:59 -0800, H. S. Teoh via Digitalmars-d wrote: […] I had to implement a drag-n-drop function in Javascript once, and the thing was one big convoluted mess, even after excluding the semantic part (which in this case is trivial). It left me really longing to have some kind of unittest framework to verify that later code changes won't break that fragile tower of cards, but alas, we didn't have any such framework available. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript [...] Oh, I *know* there are Javascript testing frameworks out there... the problem is convincing people to actually incorporate said tests as part of the development process. Sure, *I* can run the tests with my own code changes, but there are 50-100 developers working on the project who are also constantly making changes, and unless they also regularly run unittests, the whole exercise is kinda moot. T -- Do not reason with the unreasonable; you lose by definition.
Re: Do everything in Java…
On Sat, 2014-12-06 at 01:22 +, deadalnix via Digitalmars-d wrote: On Friday, 5 December 2014 at 15:28:36 UTC, Chris wrote: This is very true. Specially when mocks come into play, sometimes test become duplicated code and every time you make changes in your codebase you have to go and change the expected behaviour of mocks, which is just tedious and useless. Well poor use of mocks anyway. If a mock is having to change because the code changes (rather than the story changing) then the mock is wrong: inappropriate separation of concerns and use of mocks. Thanks for saying that. That's my experience too, especially when a module is under heavy development with frequent changes. I second this, too much mock is a lot of work down the road. I find mock immensely valuable for separating concerns, e.g GUI for controlling a network device. For integration testing mocks are invaluable, and they are useful for unit tests. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 03:09:21PM +, Russel Winder via Digitalmars-d wrote: On Fri, 2014-12-05 at 12:44 -0800, Walter Bright via Digitalmars-d wrote: On 12/5/2014 5:41 AM, H. S. Teoh via Digitalmars-d wrote: As for GUI code, I've always been of the opinion that it should be coded in such a way as to be fully scriptable. GUI's that can only operate when given real user input has failed from the start IMO, because not being scriptable also means it's non-automatable (crippled, in my book), but more importantly, it's not auto- testable; you have to hire humans to sit all day repeating the same sequence of mouse clicks just to make sure the latest dev build is still working properly. That's grossly inefficient and a waste of money spent hiring the employee. You actually need both. Scripting end-to-end tests, systems tests, etc. is important but most systems also needs humans to try things out. Oh, certainly I'm not expecting *all* tests to be automated -- there are some things that are fundamentally non-automatable, like testing look-and-feel, user experience, new feature evaluation, etc.. My complaint was that the lack of automation has caused QA to be completely occupied with menial, repetitive tasks (like navigate the same set of menus 100 times a day to test 100 developer images, just to make sure it still works as expected), that no resources are left for doing more consequential work. Instead, things have gone the opposite direction -- QA is hiring more people because the current staff can no longer keep up with the sheer amount of menial repetitive testing they have to do. If these automatable tests were actually automated, the QA department would have many resources freed up for doing other important work -- like testing more edge cases for potential problematic areas, etc.. A complementary approach is to have the UI code call semantic routines that are in non-UI code, and those semantic routines do all the semantic work. That minimizes the UI code, and hence the testing problem. The usual model is that GUI code only has GUI code and uses a Mediator and/or Façade to access any other code. Similarly separate business rules from database access (DAO, etc.). Separation of Concerns, Three Tier Model, MVC, MVP, there are masses of labels for the fundamental architecture, but it is all about modularization and testability. Most GUI apps I've seen mixed up all that code together. You haven't seen many then :-), and most of them have been crap and should have had the incantation rm -rf * applied. [...] Unfortunately, I suspect that if I adopted that policy, I'd have to nuke most of my OS. :-P T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Re: Do everything in Java…
On Fri, 2014-12-05 at 22:28 +, Freddy via Digitalmars-d wrote: […] My problems with java: no unsigned ints Indeed, right pain in the . primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) Primitive types are scheduled for removal, leaving only reference types. no operator overloading(looks at java.util.ArrayList) Biggest mistake The Green Team made. Fixed by Groovy. Oh and Scala, Ceylon, Kotlin. no templates Why would you want them for a JVM-based machine, there is no possibility of reification of type parameters, type erasure and all that mess. Scala, Kotlin, etc. have to create a vast infrastructure to deal with this. no property syntax(getters and setters are used instead even if you know the field is never going to be dynamic) Setters, getters and mutable properties are, or should be, anathema. They turn an object oriented programming language into an imperative procedural one without encapsulation. only and exactly one class per file(ALL THE IMPORTS) You can have as many classes as you want per file, but only one of them can be public. every thing must be inside a class(globals and free functions are static fields in a class) In Java. And Scala. Groovy, Kotlin, and Ceylon do things differently, the programmer can treat the JVM as having top-level functions. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via Digitalmars-d wrote: [...] primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) Primitive types are scheduled for removal, leaving only reference types. [...] Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? Sounds like I will never consider Java for computation-heavy tasks then... T -- Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.
Re: Do everything in Java…
On Sat, 2014-12-06 at 15:49 +1300, Rikki Cattermole via Digitalmars-d wrote: On 6/12/2014 3:12 p.m., H. S. Teoh via Digitalmars-d wrote: I dunno, while type erasure is certainly annoying when you actually need information about the type, it's also eliminates template bloat. I think the ideal system should be somewhere in between, where type erasure is actively performed by the compiler where the type information is not needed, while template instantiations are retained when it is needed. This should keep template bloat under control while still offering full template capabilities. D currently leans on the template bloat end of the spectrum; I think there is much room for improvement. The best solution is to not have generics, just like Javas 0 to 1.4. Every container is a container of references to Object. OK so Go has a quite neat solution. (OK this is part troll. Given all the Java, D, Go, Python,… discussions of generics I see the whole topic is beginning not to get me worked up at all.) Its a bit more then annoying. What happened when it was originally implemented was basically hacking of the compiler to support it, type erasure wasn't a design decision to my understanding. Then again the last time I checked Java's reference compiler / jvm source code it was a real mess to say the least. If I remember right an xml parser lib was at the same level in the repo as the compiler and nothing else at that level. This was only a few years ago now. Erasure originally arose because the generics team were told they couldn't change the JVM: the JVM definition was sacrosanct on the altar of backward compatibility. Of course the Annotations team were told the same thing and then changed the JVM definition anyway. So type erasure was a hack. Since then many people, probably suffering from Stockholm Syndrome, or being Scala type management infrastructure folk, no believe type erasure is the right thing for the JVM. There is a vocal contingent pushing for type parameter reification, as was done in CLR, but I think there are too many influential people saying won't happen for it to happen. Java 9 should see a far better structured JVM source code and runtime system. I really hope I'm wrong or its changed since then but who knows. Some things have changed. Some would say not enough. The LJC (of which I am a member) is on the JCP EC so we get to vote. We are generally on the side of no corporate politicking, get stuff done to help Java programmers. cf. the rewrite of the OpenJDK build system, the AdoptAJSR and AdoptJDK programs which have been hugely successful. More user groups are getting more stuff into OpenJDK than ever before. Obviously though Oracle and IBM are still the main players. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Fri, 2014-12-05 at 22:19 -0800, H. S. Teoh via Digitalmars-d wrote: […] It's enterprise code. 'Nuff said. Even though enterprise code sounds so glamorous, in reality it has a high likelihood of being a rats' nest of spaghetti code with lasagna code layered on top, an accumulation of patches upon hacks to bandaids over bugs resulting from earlier pathces, with messy sauce leaking everywhere. I've seen enough examples of actual enterprise code to know better than the idealistic image they pretend to convey. Most enterprise software is written by average programmers, and to be honest, the average programmer really is not that good. Which means I am always surprised anything works, and never surprised at the crap I see/use. But anyway, that's beside the point. :-P Type erasure does have its value -- for example, if you have a template class that represents a linked-list or tree or something like that, most of the code actually doesn't care about the type of the data at all. Code that swaps pointers to link / unlink nodes, or code that rebalances a tree, those pieces of code are mostly type-independent and can operate generically on lists or trees containing any type. Under D's template system, unless you manually factor it out, all of this code will be instantiated over and over again, once for every data type you might put into the list / tree. For non-trivial containers, the template bloat can be quite horrendous. Type erasure allows you to reuse a *single* copy of the code that handles every type of data contained. Type erasure is a total waste, reify the type parameter. If you actually want type erasure then just use Object as the type, job done. As the Java Platform API and Scala have proven you have to do a lot of work to manage type parameter under type erasure. With type reification, erasure is just one model of use. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, 2014-12-06 at 07:14 -0800, H. S. Teoh via Digitalmars-d wrote: […] Oh, I *know* there are Javascript testing frameworks out there... the problem is convincing people to actually incorporate said tests as part of the development process. Sure, *I* can run the tests with my own code changes, but there are 50-100 developers working on the project who are also constantly making changes, and unless they also regularly run unittests, the whole exercise is kinda moot. If the team is 50 to 100 programmers 1 of whom thinks testing is a good idea then I can see an unmitigatable disaster looming and the technical bosses (*) being sacked. Best bet, get a new job now. (*) management and accounting bosses never get sacked, because it is never their fault. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, 2014-12-06 at 07:24 -0800, H. S. Teoh via Digitalmars-d wrote: […] Oh, certainly I'm not expecting *all* tests to be automated -- there are some things that are fundamentally non-automatable, like testing look-and-feel, user experience, new feature evaluation, etc.. My complaint was that the lack of automation has caused QA to be completely occupied with menial, repetitive tasks (like navigate the same set of menus 100 times a day to test 100 developer images, just to make sure it still works as expected), that no resources are left for doing more consequential work. Instead, things have gone the opposite direction -- QA is hiring more people because the current staff can no longer keep up with the sheer amount of menial repetitive testing they have to do. If these automatable tests were actually automated, the QA department would have many resources freed up for doing other important work -- like testing more edge cases for potential problematic areas, etc.. On the plus side, a couple of organizations have had me in to teach their development staff Python so they can write scripting components for their UI, and teach their QA staff Python so they can script all the menial stuff testing away. Worked very well. So well in one case that the QA staff were able to have breaks and relax a bit and do really high quality end-user testing. HR thought they were slacking so sacked half of them. I think the other half of QA have now left and the product testing is clearly suffering relying solely on automated tests that are not being properly updated. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Sat, 2014-12-06 at 07:33 -0800, H. S. Teoh via Digitalmars-d wrote: […] Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? Sounds like I will never consider Java for computation-heavy tasks then... Exactly the opposite, the JVM and JIT technology is getting to the stage where boxing and hence unboxing happens less and less. For most computationally intensive tasks there will be no boxing and unboxing at all. Currently I still have to use primitive types to get Java to be faster than C and C++, but there are hints that the next round of JIT technology and JVM improvements will make that unnecessary. Of course there are elements in the JVM-verse who think that primitive types are the only way of doing this and that relying on JVM/JIT technology is anathema. This is still a moot point, no decisions as yet. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Documentation of DList in std.container seems to be inaccurate
On Wed, Nov 19, 2014 at 10:56:27PM +, Meta via Digitalmars-d wrote: On Wednesday, 19 November 2014 at 15:45:34 UTC, H. S. Teoh via Digitalmars-d wrote: The documentation was wrong before, but the whole point of removeAny() is that it removes *any* element from the container, and it's not specified *which* one is removed. The fact that a particular element (front or back or whatever) is what happens to be removed from a specific container, is something that user code should not rely on. The idea is that you just want *one* element from the container, and it doesn't matter which, so the container is free to choose the easiest one to remove. The fact that the documentation then refers specifically to front or back is a bug; user code was not supposed to rely on this. I'm pretty sure the PR that fixes this problem has been checked in, but I'm not sure why dlang.org hasn't been updated yet? Or has it only been updated in the phobos-prerelease section? T Phobos-Prerelease also says that it's removed from the front, so the documentation may not have been updated. Gah... I just checked the source code, the docs have been fixed there. Unfortunately, after std.container was recently split into multiple submodules, the ddoc build scripts were not updated properly, so the docs you see under phobos-prerelease are actually stale files. :-( I'll submit a PR for this. T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
Re: std::string responsible for half the allocations in chrome
On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ?
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 03:53:16PM +, Russel Winder via Digitalmars-d wrote: On Sat, 2014-12-06 at 07:24 -0800, H. S. Teoh via Digitalmars-d wrote: […] Oh, certainly I'm not expecting *all* tests to be automated -- there are some things that are fundamentally non-automatable, like testing look-and-feel, user experience, new feature evaluation, etc.. My complaint was that the lack of automation has caused QA to be completely occupied with menial, repetitive tasks (like navigate the same set of menus 100 times a day to test 100 developer images, just to make sure it still works as expected), that no resources are left for doing more consequential work. Instead, things have gone the opposite direction -- QA is hiring more people because the current staff can no longer keep up with the sheer amount of menial repetitive testing they have to do. If these automatable tests were actually automated, the QA department would have many resources freed up for doing other important work -- like testing more edge cases for potential problematic areas, etc.. On the plus side, a couple of organizations have had me in to teach their development staff Python so they can write scripting components for their UI, and teach their QA staff Python so they can script all the menial stuff testing away. Worked very well. So well in one case that the QA staff were able to have breaks and relax a bit and do really high quality end-user testing. HR thought they were slacking so sacked half of them. I think the other half of QA have now left and the product testing is clearly suffering relying solely on automated tests that are not being properly updated. [...] The blessing of bureaucracy at its pinnacle. :-) There is some sign of movement in my current job in the QA department towards automation, but AFAICT it still hasn't taken strong hold yet, judging by the skimpiness of QA test coverage in the code changes I submitted. One of my changes actually passed QA testing but my manager during code review caught a negated if-condition that ought to have caused major test failure. How it managed to pass testing is beyond my imagination... but it's clear that test automation still has a long ways to go around here. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 03:48:42PM +, Russel Winder via Digitalmars-d wrote: On Sat, 2014-12-06 at 07:14 -0800, H. S. Teoh via Digitalmars-d wrote: […] Oh, I *know* there are Javascript testing frameworks out there... the problem is convincing people to actually incorporate said tests as part of the development process. Sure, *I* can run the tests with my own code changes, but there are 50-100 developers working on the project who are also constantly making changes, and unless they also regularly run unittests, the whole exercise is kinda moot. If the team is 50 to 100 programmers 1 of whom thinks testing is a good idea then I can see an unmitigatable disaster looming and the technical bosses (*) being sacked. Best bet, get a new job now. (*) management and accounting bosses never get sacked, because it is never their fault. [...] Disaster *looming*? Haha... disaster has been *happening* for the past how many years now... Hence my earlier references to regressions spiralling out of control and new features breaking old ones like there's no tomorrow, and developers scrambling like mad to fix them all in a whack-a-mole bid to bash the product into shippable form by the deadline, of which we tend to be informed the week of (or sometimes, the Friday afternoon before a Monday deadline)... Fortunately(?), no one has been sacked yet. Part of it may have to do with the fact that practically all our customers are corporate, and corporate customers tend to value business relationships and deals above actual product quality, even when they're on the receiving end. (Just my cynical guess, though. I have no concrete evidence of this. :-P) T -- Computers aren't intelligent; they only think they are.
Re: std::string responsible for half the allocations in chrome
On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton Wakeling via Digitalmars-d wrote: On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ? Immutable, because then you can freely use slices as substrings without worrying that the substring you hand to function X might get modified by unrelated function Y while function X is not quite done with processing it yet. D arrays in general, because .length eliminates an entire class of performance killers, namely strlen(). :-P Plus, the GC allows you to append to strings without worrying that other references to the original string will also unwittingly get lengthened (unlike in C, where appending to a char* will cause the lengthened string to be visible via other copies of that char* too -- the solution is usually to call strdup() everywhere, which is another performance killer). T -- A linguistics professor was lecturing to his class one day. In English, he said, A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative. A voice from the back of the room piped up, Yeah, yeah.
Re: Do everything in Java…
On Saturday, 6 December 2014 at 15:14:23 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 08:46:58AM +, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via Digitalmars-d wrote: On 12/5/2014 11:54 PM, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote: Code review my friend. Nothing gets in without review, and as won't usually don't enjoy the prospect of having to fix the shit of a coworker, one ensure that coworker wrote proper tests. Good luck making that work in companies. Code review is something for open source projects and agile conferences. I've worked at several companies, both large and gigantic, and it's worked very well at all of them. Code reviews are an important part of healthy and quality code development processes. Maybe I have worked at wrong companies then. In 20 years of career I can count with one hand those that did it, and most developers hated it. Never lasted more than a few meetings. [...] Huh, what...?? Meetings? For code review??? How does that even work...? Easy, the meetings get scheduled with each developer getting a module for review. Those developers then print the code and get some days for review until the meeting. The meeting takes place and afterwards each developer updates its own module witb the gathered feedback. The scenario you described I have only seen live in startups. I never saw a corporate institution care about code review, specially if the projects have offshored teams, as the ratio is usually 10:1.
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 04:43:56PM +, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 15:14:23 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 08:46:58AM +, Paulo Pinto via Digitalmars-d wrote: On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via Digitalmars-d wrote: [...] I've worked at several companies, both large and gigantic, and it's worked very well at all of them. Code reviews are an important part of healthy and quality code development processes. Maybe I have worked at wrong companies then. In 20 years of career I can count with one hand those that did it, and most developers hated it. Never lasted more than a few meetings. [...] Huh, what...?? Meetings? For code review??? How does that even work...? Easy, the meetings get scheduled with each developer getting a module for review. Those developers then print the code and get some days for review until the meeting. The meeting takes place and afterwards each developer updates its own module with the gathered feedback. Whoa. People actually do that??! If that's how code reviews are carried out, I can totally see why it wouldn't work. While I'm OK with spending 15-20 minutes reviewing a prospective code diff to be merged into mainline, reviewing an entire module would take up way too much time, and would be too quickly invalidated (as more changes pile up) to be of any long-lasting value. Some of the code I work on contains files with 4000+ lines of code (sometimes up to 8000+ lines); printing that would fill a small book, and would take at least a week (if not more!) to thoroughly review. By then, the review would be worthless 'cos the 50 other developers have been making changes for a *week*. That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. While not all of the work would touch a single file, enough of it would touch code related to that file, that will make any static code review essentially worthless by the time it's done. Such an approach cannot possibly work in today's scale of software projects. The scenario you described I have only seen live in startups. I never saw a corporate institution care about code review, specially if the projects have offshored teams, as the ratio is usually 10:1. If code review means the process you describe above, yeah, I can totally see why!! My employer can't be accurately described as a startup anymore, as it has grown to thousands of employees worldwide over the past 10+ years of its existence. But despite all the other flaws I often bemoan, code review is something ingrained in company culture. If code that passes through the review protocol I described still ends up being of such inferior quality as I witness every day, then I truly dread seeing what it turns into when there is no review process at all!! (Or not... I guess it would just be IOCCC all over again on a larger scale. :-P After all, I *did* write a monstrosity that won an ignoble award from the IOCCC once... so I just have to get used to doing that on a regular basis. :-P) In any case, the only code review process that I can see having any chance of being practicable is review per change request. Reviewing by module is simply not feasible in today's kind of software development, esp. where large teams are involved. T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
D semantics, shared as a heap storage specifier
This is the only issue preventing a truly thread-local GC for better
multi-core scalability for D applications. From:
https://github.com/D-Programming-Language/druntime/pull/1057#issuecomment-65904128
The best way to achieve a thread-local GC would be to improve and
enforce `shared`-correctness in Phobos/druntime (at first). We need to
start considering `shared` as a heap storage attribute as well, for
consistency. An optional compiler warning (through a flag) would be a
start.
If even a 30% speedup is possible down the line, it's worth it. The more
threads, the more improvements.
There's also some new opportunities with this. Here's an example that
involves TLS data to influence the behavior of shared objects, without
using a global `T[Thread]` hashmap.
```D
shared class A {
private bool m_init; // different on every thread
public shared:
AA m_impl;
synchronized void init() {
if (!m_init)
m_impl.add(Thread.getThis());
}
...
}
```
Re: Documentation of DList in std.container seems to be inaccurate
On Sat, Dec 06, 2014 at 07:58:08AM -0800, H. S. Teoh via Digitalmars-d wrote: On Wed, Nov 19, 2014 at 10:56:27PM +, Meta via Digitalmars-d wrote: On Wednesday, 19 November 2014 at 15:45:34 UTC, H. S. Teoh via Digitalmars-d wrote: The documentation was wrong before, but the whole point of removeAny() is that it removes *any* element from the container, and it's not specified *which* one is removed. The fact that a particular element (front or back or whatever) is what happens to be removed from a specific container, is something that user code should not rely on. The idea is that you just want *one* element from the container, and it doesn't matter which, so the container is free to choose the easiest one to remove. The fact that the documentation then refers specifically to front or back is a bug; user code was not supposed to rely on this. I'm pretty sure the PR that fixes this problem has been checked in, but I'm not sure why dlang.org hasn't been updated yet? Or has it only been updated in the phobos-prerelease section? T Phobos-Prerelease also says that it's removed from the front, so the documentation may not have been updated. Gah... I just checked the source code, the docs have been fixed there. Unfortunately, after std.container was recently split into multiple submodules, the ddoc build scripts were not updated properly, so the docs you see under phobos-prerelease are actually stale files. :-( I'll submit a PR for this. [...] https://github.com/D-Programming-Language/phobos/pull/2788 T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Re: Do everything in Java…
On 2014-12-05 03:39, deadalnix wrote: Also relevant: http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application Haha, I saw how small the scroll bar was and didn't bother reading any more than the title. -- /Jacob Carlborg
Re: Do everything in Java…
On Saturday, 6 December 2014 at 15:35:57 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via Digitalmars-d wrote: [...] primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) Primitive types are scheduled for removal, leaving only reference types. [...] Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? Sounds like I will never consider Java for computation-heavy tasks then... T It the same approach taken by .NET, Eiffel and many other languages. Just because it looks like an object to the eyes of the programmer, it doesn't mean it is one. So when Java finally gets value types (either on 9 or 10 if the effort is too much), then primitives might become alias just like in .NET. -- Paulo
Re: Do everything in Java…
The majority of corporations I have worked for, software development is not their main business, so they tend to disregard anything that doesn't contribute to their business as waste of money. I imagine your employer main business is software development. -- Paulo
Re: std::string responsible for half the allocations in chrome
On Saturday, 6 December 2014 at 16:10:20 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 05/12/14 23:03, deadalnix via Digitalmars-d wrote:
http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/
Looks like someone need immutable(char)[] .
Someone asked me the other day, and I realized I didn't have a
ready answer as I'd never particularly considered it: why is it
important/beneficial that the string type be immutable(char)[] ?
Because string literals must be in the read only part of the
program.
void test()
{
string s=abc;
callFunc(s);
s[0]='z'//next call to test will set a=zbc
}
Otherwise the compiler would have to create a copy everytime you
assign a string literal to variable(call .dub for you).
Find symbol in unknown module at compile time?
Hi, I have a mixin, which can mix a class into any module. At compile time, I will know the name of the class, it's base class, and that it is at global scope in some module. Is there any way to find this class from a different module at compile time? Thanks
Re: Do everything in Java…
On 12/6/2014 7:12 AM, H. S. Teoh via Digitalmars-d wrote: However, all this level of review kinda loses a lot of its effectiveness because we have no unittesting system, so regressions are out of control. :-( The code is complex enough that even with all this review, things still slip through. The lack of automation also means QA tests are sometimes rather skimpy and miss obvious regressions. Having automated unittesting would go a long ways in improving this situation. Without the dmd compiler test suite, making progress with the compiler would be simply impossible.
Re: DIP69 - Implement scope for escape proof references
On 12/5/2014 3:59 PM, deadalnix wrote:
On Friday, 5 December 2014 at 21:32:53 UTC, Walter Bright wrote:
I don't believe this is correct. Rvalues can be assigned, just like:
__gshared int x;
{ int i; x = i; }
i's scope ends at the } but it can still be assigned to x.
It work even better when i has indirections.
I understand what you're driving at, but only a scoped rvalue would not be
copyable.
The DIP say nothing about scoped rvalue having different behavior
than non scoped ones.
Can you propose some new wording?
I originally had scope only apply to ref, but that made
having scoped classes
impossible.
Promoting scoped class on stack is an ownership problem, and out
of scope (!). It make sense to allow it as an optimization.
Problem is, lifetime goes to infinite after indirection, so I'm
not sure what the guarantee is.
The guarantee is there will be no references to the class instance after the
scoped class goes out of scope.
Through use of that view. I see it as follow:
- When unconsumed owner goes out of scope, it can (must ?) be
free automatically.
- scope uses do not consume.
- When the compiler see a pair of alloc/free, it can promote on
stack.
That is a much more useful definition as it allow for stack
promotion after inlining:
class FooBuilder {
Foo build() { return new Foo(); }
}
class Foo {}
void bar() {
auto f = new FooBuilder().build();
// Use f and do not consume...
}
This can be reduced in such a way no allocation happen at all.
Yes, but I think the proposal allows for that.
I cause everything reached through the view to be scope and
obliviate the need for things like (*e) having special meaning.
Are you suggesting transitive scope?
For rvalues, yes. Not for lvalues.
I don't think that is workable.
Re: Do everything in Java…
On Sat, Dec 06, 2014 at 06:46:58PM +, Paulo Pinto via Digitalmars-d wrote: The majority of corporations I have worked for, software development is not their main business, so they tend to disregard anything that doesn't contribute to their business as waste of money. Yes, but what they *don't* realize is that by not adopting proper code maintenance practices, they're actually incurring more waste of money by having their tech staff tied up fixing regressions rather than making progress. I imagine your employer main business is software development. Yes. I guess that makes a big difference. :) On Sat, Dec 06, 2014 at 01:50:24PM -0800, Walter Bright via Digitalmars-d wrote: On 12/6/2014 7:12 AM, H. S. Teoh via Digitalmars-d wrote: However, all this level of review kinda loses a lot of its effectiveness because we have no unittesting system, so regressions are out of control. :-( The code is complex enough that even with all this review, things still slip through. The lack of automation also means QA tests are sometimes rather skimpy and miss obvious regressions. Having automated unittesting would go a long ways in improving this situation. Without the dmd compiler test suite, making progress with the compiler would be simply impossible. And even then, regressions still do slip through every release. I can't imagine what it would be like if we *didn't* have a test suite... dmd would be unusably broken. T -- It's bad luck to be superstitious. -- YHL
Re: DIP69 - Implement scope for escape proof references
On 12/6/2014 1:50 AM, Manu via Digitalmars-d wrote: I didn't fully understand Manu's issue, but it was about 'ref' not being inferred by template type deduction. I didn't understand why 'auto ref' did not work for him. I got the impression that he was trying to program in D the same way he'd do things in C++, and that's where the trouble came in. NO!! I barely program C++ at all! I basically write C code with 'enum' and 'class'. NEVER 'template', and very rarely 'virtual'. Your impression is dead wrong. I apologize for misunderstanding you. It's exactly as Marc says, we have the best tools for dealing with types of any language I know, and practically none for dealing with 'storage class'. In my use of meta in D, 'ref' is the single greatest cause of complexity, code bloat, duplication, and text mixins. I've been banging on about this for years! I've been over it so many times. I'll start over if there is actually some possibility I can convince you? Is there? I know there's no easy way to derive a storage class from an expression. The difficulty in my understanding is why this is a great cause of problems for you in particular (and by implication not for others). There's something about the way you write code that's different. I've lost faith that I am able to have any meaningful impact on issues that matter to me, and I'm fairly sure at this point that my compounded resentment and frustration actually discredit my cause, and certainly, my quality of debate. This is incorrect, you had enormous influence over the vector type in D! And I wish you had more. There has been a couple of instances where the situation has been appropriate that I've tried to make use of auto ref, but in each case, the semantics have never been what I want. I don't really know what you want. Well, perhaps a better statement is 'why', not what. ref is a bad design. C++'s design isn't fantastic, and I appreciate that D made effort to improve on it, but we need to recognise when the experiment was a failure. D's design is terrible; it's basically orthogonal to the rest of the language. It's created way more complicated edge cases for me than C++ references ever have. Anyone who says otherwise obviously hasn't really used it much! Don't double down on that mistake with scope. Why does your code need to care so much about to ref or not to ref? That's the central point here, I think. My intended reply to this post was to ask you to justify making it a storage class, and why the design fails as a type constructor? Can we explore that direction to it's point of failure? As a storage class, it runs the risk of doubling out existing bloat caused by ref. As a type constructor, I see no disadvantages. It even addresses some of the awkward problems right at the face of storage classes, like how/where the attributes actually apply. Type constructors use parens; ie, const(T), and scope(T) would make that matter a lot more clear. Apart from the storage class issue, it looks okay, but it gives me the feeling that it kinda stops short. Marc's proposal addressed more issues. I feel this proposal will result in more edge cases than Marc's proposal. The major edge case that I imagine is that since scope return values can't be assigned to scope local's, that will result in some awkward meta, requiring yet more special cases. I think Mark's proposal may be a lot more relaxed in that way. The disadvantages of making it a type qualifier are: 1. far more complexity. Type constructors interact with everything, often in unanticipated ways. We spent *years* working out issues with the 'const' type qualifier, and are still doing so. Kenji just fixed another one. 2. we are never going to get users to use 'scope' qualifiers pervasively. It's been a long struggle to get 'const' used. 3. we added 'inout' as a type qualifier to avoid code duplication engendered by 'const'. It hurts my brain to even think about how that might interact with 'scope' qualifiers. Yes, I agree unequivocably, that 'scope' as a type qualifier is more expressive and more powerful than as a storage class. Multiple inheritance is also more expressive and more powerful than single inheritance. But many times, more power perhaps isn't better than redoing the program design to use something simpler and less complex.
Re: DIP69 - Implement scope for escape proof references
On 12/6/2014 5:30 AM, Marc Schütz schue...@gmx.net wrote:
On Friday, 5 December 2014 at 23:58:41 UTC, Walter Bright wrote:
As you point out, 'ref' is designed for this.
I wouldn't call it designed, but repurposed...
Perhaps, but the original reason to even have 'ref' was so it could be a
restricted pointer type that could be passed down a call hierarchy, but not up.
struct Container(T) {
scope ref T opIndex(size_t index);
}
void bar(scope ref int a);
Container c;
bar(c[42]);// ok
scope ref tmp = c[42]; // nope
Both cases should be fine theoretically; the real owner lives longer than
`tmp`. Unfortunately the compiler doesn't know about this.
Right, though the compiler can optimize to produce the equivalent.
??? This is a problem on the semantic level, unrelated to optimization:
// contrived example to illustrated the point
Container c;
scope ref x = c[42]; // not
scope ref y = c[44]; // ...
scope ref z = c[13]; // allowed
foo(x, y, z, x+y, y+z, z+x, x+y+z);
// workaround, but error-prone and has different semantics
// (opIndex may have side effects, called multiple times)
foo(c[42], c[44], c[13], c[42]+c[44], c[44]+c[13], c[13]+c[42],
c[42]+c[44]+c[13]);
// another workaround, same semantics, but ugly and unreadable
(scope ref int x, scope ref int y, scope ref int z) {
foo(x, y, z, x+y, y+z, z+x, x+y+z);
}(c[42], c[44], c[13]);
You are correct, and it remains to be seen if these occur enough to be a problem
or not. The workarounds do exist, though. Another workaround:
scope ref tmp = c[42];
becomes:
auto scope ref tmp() { return c[42]; }
Ok, so let's drop bar2() and bar4().
scope ref int foo();
scope ref int bar1(ref int a) {
return a;
}
ref int bar3(ref int a) {
return a;
}
ref int baz_noscope(/*scope*/ ref int a);
foo().bar1().baz_noscope();
foo().bar3().baz_noscope();
And now? In particular, will the return value of `bar3` be treated as if it were
`scope ref`?
Yes.
Re: Find symbol in unknown module at compile time?
On Saturday, 6 December 2014 at 20:22:13 UTC, bitwise wrote: Hi, I have a mixin, which can mix a class into any module. At compile time, I will know the name of the class, it's base class, and that it is at global scope in some module. Is there any way to find this class from a different module at compile time? Thanks Any thoughts on having something like this? symbol __traits(find, symbolName);
Re: DIP69 - Implement scope for escape proof references
On Saturday, 6 December 2014 at 11:06:16 UTC, Jacob Carlborg wrote: On 2014-12-06 10:50, Manu via Digitalmars-d wrote: I've been over it so many times. I suggest you take the time and write down how your vision of ref looks like and the issue with the current implementation. A blog post, a DIP or similar. Then you can easily refer to that in cases like this. Then you don't have to repeat yourself so many times. That's what I did when there was a lot of talk about AST macros. I was tired of constantly repeating myself so I created a DIP. It has already saved me more time than it took to write the actual DIP. @Manu Seconded. Please create even short one. I coulnd'd find any example of use case you are referring to (as you said I don't use Dref so often) . I plan to apply D for embedded systems, so full control is a must. But so far Water still has the most accurate taste according to my experience. BTW. I consider game devs to be the most underpaid programmers, so your perspective is very precious to me. Cheers Piotrek
Re: Do everything in Java…
On Sat, 06 Dec 2014 16:43:56 + Paulo Pinto via Digitalmars-d digitalmars-d@puremagic.com wrote: Easy, the meetings get scheduled with each developer getting a module for review. Those developers then print the code and get some days for review until the meeting. The meeting takes place and afterwards each developer updates its own module witb the gathered feedback. what a mess! the thing i really don't want to do is to have a work where thay have all those useless meetings. signature.asc Description: PGP signature
Re: Find symbol in unknown module at compile time?
On Sat, 06 Dec 2014 20:22:12 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: Hi, I have a mixin, which can mix a class into any module. At compile time, I will know the name of the class, it's base class, and that it is at global scope in some module. Is there any way to find this class from a different module at compile time? why do you need that? signature.asc Description: PGP signature
Re: DIP69 - Implement scope for escape proof references
On 7 December 2014 at 08:15, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12/6/2014 1:50 AM, Manu via Digitalmars-d wrote:
I didn't fully understand Manu's issue, but it was about 'ref' not being
inferred by template type deduction. I didn't understand why 'auto ref'
did
not work for him. I got the impression that he was trying to program in D
the same way he'd do things in C++, and that's where the trouble came in.
NO!!
I barely program C++ at all! I basically write C code with 'enum' and
'class'. NEVER 'template', and very rarely 'virtual'.
Your impression is dead wrong.
I apologize for misunderstanding you.
It's exactly as Marc says, we have the best tools for dealing with
types of any language I know, and practically none for dealing with
'storage class'.
In my use of meta in D, 'ref' is the single greatest cause of
complexity, code bloat, duplication, and text mixins. I've been
banging on about this for years!
I've been over it so many times.
I'll start over if there is actually some possibility I can convince
you? Is there?
I know there's no easy way to derive a storage class from an expression. The
difficulty in my understanding is why this is a great cause of problems for
you in particular (and by implication not for others). There's something
about the way you write code that's different.
Perhaps it's the tasks I typically perform with meta?
I'm a fairly conservative user of templates, but one place where they
shine, and I'm always very tempted to use them, is the task of
serialisation, and cross-language bindings.
Those tasks typically involve mountains of boilerplate, and D is the
only language expressive enough to start to really automate that
mechanical mess.
I've done extensive work bindings to C/C++, Lua, and C#. They're all
subtly different tasks, but share a lot in common, and the major
characteristic which reveals my problems with things like ref, and
auto ref, is that these things aren't open to interpretation. They're
not cases where the compiler can make decisions for you (ie, auto ref
fails), and the ABI + API are strict (ie, ref must match correctly).
There's a lot more more to it, but perhaps I'm among few who have had
such extensive need to engage in these tasks?
I've lost faith that I am able to have any meaningful impact on issues
that matter to me, and I'm fairly sure at this point that my
compounded resentment and frustration actually discredit my cause, and
certainly, my quality of debate.
This is incorrect, you had enormous influence over the vector type in D! And
I wish you had more.
I appreciate that. That was uncontroversial though; I didn't need to
spend months or years trying to justify my claims on that issue. I
feel like that was a known item that was just somewhere slightly down
the list, and I was able to bring it forward.
I was never in a position where I had to argue against Andrei to sell that one.
I have std.simd sitting here, and I really want to finish it, but I
still don't have the tools to do so.
I need, at least, forceinline to complete it, but that one *is*
controversial - we've talked about this for years.
GDC and LDC both have a forceinline, so I could theoretically support
those compilers, but then I can't practically make use of them without
some sort of attribute aliasing system, otherwise I need to triplicate
the code for each compiler, just to insert a different (compiler
specific) forceinline attribute name. It'd be really great if we
agreed on just one.
There is also a practical problem with GCC (perhaps it's an
incompatbility with my std.simd design), where I need to change the
sse-level between functions.
There is a GCC attribute to do this ('target'), but it would rely on,
at least, a few subtle tweaks. In this case, I need to be able to feed
a template argument to a UDA, which doesn't work because UDA
declarations seem to be parsed prior to knowledge of functions
template args. There may be a further problem with GCC though which I
haven't been able to prove yet though.
The reason for this is that an important design goal for my work was
to be able to semi-automatically generate multiple code paths for
different SSE versions, which can be selected at runtime based on
available hardware.
It's a particularly awkward issue in C/C++, usually requiring you to
have multiple modules which are each built with different compile
flags, and then do some magic while linking to resolve the runtime
selection problem.
Anyway, I have been able to use SIMD directly in my own software with
the support we have, but I haven't been able to complete the library
that I want to produce.
I need a little more language support. I've reached out a few times,
but there hasn't been too much interest in the past. I really do wanna
finish it one of these days though!
There has been a couple of instances where the situation has been
appropriate that I've tried to make use of auto ref, but in each
Re: Do everything in Java…
On Saturday, 6 December 2014 at 16:23:46 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 03:48:42PM +, Russel Winder via Digitalmars-d wrote: On Sat, 2014-12-06 at 07:14 -0800, H. S. Teoh via Digitalmars-d wrote: […] Oh, I *know* there are Javascript testing frameworks out there... the problem is convincing people to actually incorporate said tests as part of the development process. Sure, *I* can run the tests with my own code changes, but there are 50-100 developers working on the project who are also constantly making changes, and unless they also regularly run unittests, the whole exercise is kinda moot. If the team is 50 to 100 programmers 1 of whom thinks testing is a good idea then I can see an unmitigatable disaster looming and the technical bosses (*) being sacked. Best bet, get a new job now. (*) management and accounting bosses never get sacked, because it is never their fault. [...] Disaster *looming*? Haha... disaster has been *happening* for the past how many years now... Hence my earlier references to regressions spiralling out of control and new features breaking old ones like there's no tomorrow, and developers scrambling like mad to fix them all in a whack-a-mole bid to bash the product into shippable form by the deadline, of which we tend to be informed the week of (or sometimes, the Friday afternoon before a Monday deadline)... Fortunately(?), no one has been sacked yet. Part of it may have to do with the fact that practically all our customers are corporate, and corporate customers tend to value business relationships and deals above actual product quality, even when they're on the receiving end. (Just my cynical guess, though. I have no concrete evidence of this. :-P) T +1,000 ( D scope should be smaller than C. JRE/CLR should be of limits. Also this one dude(Linus) talks about a big lang(C++) and it's advocates: - http://harmful.cat-v.org/software/c++/linus I'm sure he he has no credibility /s )
Re: Find symbol in unknown module at compile time?
why do you need that? I've made a reflection library which creates metadata on a per-module basis. usage would be like this: [code] module test; // classes, methods, etc.. mixin(reflect!test); // generates reflection here so private members are accessible [/code] -or- [code] module main; import test; mixin(reflect!test); // oops, test is a static library, must create reflection here instead [/code] If the reflection mixin is in the same module that it's reflecting, it can be easily found, but in the case of a static library where reflection information has to be created in a separate module, other modules won't be able to locate the reflection.
Re: Find symbol in unknown module at compile time?
On Sun, 07 Dec 2014 01:12:52 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: If the reflection mixin is in the same module that it's reflecting, it can be easily found, but in the case of a static library where reflection information has to be created in a separate module, other modules won't be able to locate the reflection. why don't create a dummy module which only keeps list of all known objects, and create `shared static this ()` constructors which will just register everything in that module? in compile-time other modules can inspect things with traits, and in run-time you'll have one central place with all known metadata, and with autoregistration. and it's doesn't matter where you call your metadata generation mixin, all data will end registered in one place. signature.asc Description: PGP signature
Re: DIP69 - Implement scope for escape proof references
On 12/6/2014 4:49 PM, Manu via Digitalmars-d wrote:
On 7 December 2014 at 08:15, Walter Bright via Digitalmars-d
There's a lot more more to it, but perhaps I'm among few who have had
such extensive need to engage in these tasks?
I don't know, but it's a mystery to me what you're doing that there's no
reasonable alternative, or why this is such an extensive issue for you.
This is incorrect, you had enormous influence over the vector type in D! And
I wish you had more.
I appreciate that. That was uncontroversial though; I didn't need to
spend months or years trying to justify my claims on that issue. I
feel like that was a known item that was just somewhere slightly down
the list, and I was able to bring it forward.
I was never in a position where I had to argue against Andrei to sell that one.
UDA was controversial, and was one of your initiatives.
I have std.simd sitting here, and I really want to finish it, but I
still don't have the tools to do so.
I need, at least, forceinline to complete it, but that one *is*
controversial - we've talked about this for years.
I proposed a DIP to fix that, but it could not get reasonable consensus.
http://wiki.dlang.org/DIP56
You did, after all, convince me that we need an always inline and a never
inline method.
There is also a practical problem with GCC (perhaps it's an
incompatbility with my std.simd design), where I need to change the
sse-level between functions.
There is a GCC attribute to do this ('target'), but it would rely on,
at least, a few subtle tweaks. In this case, I need to be able to feed
a template argument to a UDA, which doesn't work because UDA
declarations seem to be parsed prior to knowledge of functions
template args. There may be a further problem with GCC though which I
haven't been able to prove yet though.
I don't know why this needs to be a deduced template argument.
The reason for this is that an important design goal for my work was
to be able to semi-automatically generate multiple code paths for
different SSE versions, which can be selected at runtime based on
available hardware.
No argument there.
I need a little more language support. I've reached out a few times,
but there hasn't been too much interest in the past. I really do wanna
finish it one of these days though!
I want it done, too :-)
I don't really know what you want. Well, perhaps a better statement is
'why', not what.
Because a function is a function. It's a fundamental and ultimately
*simple* element of a language, with simple and reliable in behaviour;
you write a function, compiler emits some code with a matching symbol
name. There is perhaps nothing more simple or fundamental to the
language.
A template is not a function. It may *generate* a function, but now
we've added many extra details which require careful consideration and
handling, like where the code is, or isn't, emitted? How many
permutations are there? What about static/dynamic libraries? Calling
with various, or arbitrary types, always required careful
consideration, more so than an explicit type.
Templates are a powerful (often dangerous) **tool**, which should only
be applied deliberately and very carefully.
Obviously auto-ref gives hard answers to some of those questions, but
it is still a template, and that instantly makes it much more complex.
I view a template function as a function that takes both compile-time and
run-time arguments, not as a function generator. (The latter is an
implementation artifact.)
Making a function that has nothing to do with templates into a
template is not what I want... it couldn't be further from what I ever
wanted!
I don't see any problem with:
T func()(runtime args ...) { ... }
That idiom has found various uses in practice.
The ABI is different; there are 2 functions now (or zero, until one is
called). Thich means taking the address of a function with auto-ref is
a complex issue.
ref-ness isn't a decision I ever want the compiler to make for me.
But why?
I either want ref, or I don't, and I will state that to the compiler
explicitly.
This is especially true when interacting with other languages; while D
remains in relative infancy, I think that is an overwhelmingly common
situation when a project is modestly large.
The set of other languages that support ref parameters is [C++]. None others I
know of that are accessible from D. Is it commonplace in C++ to have these
overloads:
T foo(S s);
T foo(S s);
? Such a practice would at least raise an eyebrow for me.
In the situation where templates are involved, it would be nice to be
able to make that explicit statement that some type is ref or not at
the point of template instantiation, and the resolution should work
according to the well-defined rules that we are all familiar with.
Within a complex template, if logic should be performed, we have
powerful tools to do that already; nobody ever complains about
Unqual!, or PointerTarget!... these
Re: Find symbol in unknown module at compile time?
why don't create a dummy module which only keeps list of all
known
objects, and create `shared static this ()` constructors which
will
just register everything in that module?
I am actually doing this already, but this only solves for
finding information at runtime.
One or more of these are created in a module by the mixin above:
class testReflection : Reflection {
override void register(){ ... }
static const(ModuleDecl) info = ... ;
}
abstract class Reflection {
void register();
}
static this() {
foreach(m; ModuleInfo) {
foreach(c; m.localClasses()) {
if(c.base is Reflection.classinfo) {
Reflection refl = cast(Reflection)c.create();
refl.register();
}
}
}
}
So as long as 'Test_Reflection' is in the module that it's
reflecting, I can get the info I need like this:
__traits(getMember, __traits(getMember, test, test ~
Reflection), info);
But, this doesn't work if the mixin is instantiated in a separate
module.
Now when the reflection actually can be found, the entire
reflection data hierarchy is accessible at compile time.
Either one of these could work:
Tuple(symbols) __traits(find, string name)
Tuple(alias or string) __traits(allModules)
I have minimal experience with compiler technology right now, and
I've just recently gotten my own fork of DMD set up, but wouldn't
the first option be as simple as looking the name up in a symbol
table and returning it?
Re: Find symbol in unknown module at compile time?
On Sun, 07 Dec 2014 05:42:31 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: what you actually want is some cross-module compile-time data storage. this is impossible to implement. at least to make it reliable. with separate compilation, for example, you can't get list of all modules, 'cause we can link other unimported modules to the final executable. this is somethimes useful with extern, for example. and there is no such thing as main module too, so there is no root for symbols. besides, some templates can be not instantiated at the time you doing compile-time reflection, for example. that is why my console-ng requires that register all mixin must be the last line in the module. with some efforts and hackery you can walk all imported modules, but this can fail at unexpected places. tl;dr: things aren't that easy when it comes to compile-time reflection. either live that to runtime or write compile-time wrappers and restrict compile-time reflection usage to well-defined places and patterns. signature.asc Description: PGP signature
Re: DIP69 - Implement scope for escape proof references
Walter Bright wrote in message news:m60oa4$kd5$1...@digitalmars.com...
I have std.simd sitting here, and I really want to finish it, but I
still don't have the tools to do so.
I need, at least, forceinline to complete it, but that one *is*
controversial - we've talked about this for years.
I proposed a DIP to fix that, but it could not get reasonable consensus.
http://wiki.dlang.org/DIP56
You did, after all, convince me that we need an always inline and a
never inline method.
From the DIP:
If a pragma specifies always inline, whether or not the target function(s)
are actually inlined is
implementation defined, although the implementation will be expected to
inline it if practical.
Implementations will likely vary in their ability to inline.
I expect a proposal in which 'always' means inline or give an error would
be much better received.
The thing is, I don't understand *why* you want to wrangle storage
classes. What is the coding pattern?
That's the wrong question. I could ask why do you hate ref as a storage
class?
I suspect the answer is that sometimes it is useful to ensure some
parameters are passed by reference, not by value. With ref as a type, this
would be trivial:
template MyParamType(T)
{
static if (someCriteria!T)
alias MyParamType = ref(T);
else
alias MyParamType = T;
}
void myFunction(T, U, V)(const MyParamType!T, const MyParamType!U, const
MyParamType!V)
{
...
}
Re: DIP69 - Implement scope for escape proof references
On Saturday, 6 December 2014 at 12:38:24 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 December 2014 at 04:31:48 UTC, Sebastiaan Koppe wrote: What about also adding the inverse of scope? Then scope can be inferred. As in: ``` void foo(int* p); void free(P)(consume P* p); Yes, this is much better. When I suggested it, it was rejected because D is too concerned about breaking existing code. Which is a not-very-good argument since this breaking change is concervative (you only have to add consume or something similar when the compiler complains). Hmm, I see. Whenever I suggest to break something at my job - which, admittedly is much easier there than in a language - I get faced with some serious reluctance. My argument is always the same: It is going to make you happy, eventually. How would it break anything though? Wouldn't functions eligible for `consume` already have the programmer ensuring the arguments haven't escaped before/after the function call? In case they did a bad job - sure it would break - but it would have been a bug. The obvious solution is to do as you suggest and in addition do all @safe analysis on a high level IR layer using dataflow through and through. I am a big proponent of dataflow analyses, but I got the feeling people think is it pretty hard. Couldn't find much detailed papers on it, so I don't know.
Re: Sorted Array Wrapper Range
On Thursday, 4 December 2014 at 07:58:25 UTC, Tobias Pankrath wrote: I see two typical variants: - Direct: Always sorts on write() and modify() - Lazy: Sorts lazily on read() read() of course uses binarySearch You won't be able to grow that range, would you? Why, because of slice invalidation?
Re: Sorted Array Wrapper Range
On Saturday, 6 December 2014 at 14:10:21 UTC, Nordlöw wrote: On Thursday, 4 December 2014 at 07:58:25 UTC, Tobias Pankrath wrote: I see two typical variants: - Direct: Always sorts on write() and modify() - Lazy: Sorts lazily on read() read() of course uses binarySearch You won't be able to grow that range, would you? Why, because of slice invalidation? Because a RandomAccessRange has no means to grow in general. Compare your proposed wrapper to http://dlang.org/phobos/std_container.html#.BinaryHeap
Re: Sorted Array Wrapper Range
On Saturday, 6 December 2014 at 14:14:18 UTC, Tobias Pankrath wrote: Because a RandomAccessRange has no means to grow in general. Compare your proposed wrapper to http://dlang.org/phobos/std_container.html#.BinaryHeap So what should the basic operations in a SortedRange wrapper template be? And how should the wrapped type be restricted?
Delegate returning itself
Is there a way to create a delegate that returns itself? alias MyDelegate delegate() MyDelegate; // OR alias MyDelegate = MyDelegate delegate(); When I compile this I get: Error: alias MyDelegate recursive alias declaration The error makes sense but I still feel like there should be a way to create a delegate that returns itself. Maybe there's something I haven't thought of. Does anyone have an idea on how to do this?
Re: Delegate returning itself
The problem is the recursive *alias* rather than the delegate. Just don't use the alias name inside itself so like alias MyDelegate = void delegate() delegate(); will work. The first void delegate() is the return value of the MyDelegate type.
repack ubyte[] to use only 7 bits
Is there a standard way to do this? The code below is untested, as I
haven't yet written the x7to8 routine, and came up with a better way to
do what this was to accomplish, but it feels as if this should be
somewhere in the standard library, if I could only find it.
/** Repack the data from an array of ubytes into an array of ubytes of
* which only the last 7 are significant. The high bit will be set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 = 0xfe = 1110, 0x00 =
//1 = 0x7f = 0111, 0x00 =
//2 = 0x3f = 0011, 0x80 = 1000
//3 = 0x1f = 0001, 0xc0 = 1100
//4 = 0x0f = , 0xe0 = 1110
//5 = 0x07 = 0111, 0xf0 =
//6 = 0x03 = 0011, 0xf8 = 1000
//7 = 0x01 = 0001, 0xfc = 1100
if (bin.length 1)returnbout;
intfByte, fBit;
while(fByte bin.length)
{if (fByte + 1 == bin.length fBit 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] 0x7f;
break;
case2:
ubyteb1=(bin[fByte] 0x3f) 1;
ubyteb2=(bin[fByte + 1] 0x80) 7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] 0x1f) 2;
ubyteb2=(bin[fByte + 1] 0xc0) 6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] 0x0f) 3;
ubyteb2=(bin[fByte + 1] 0xe0) 5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] 0x07) 4;
ubyteb2=(bin[fByte + 1] 0xf0) 4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] 0x03) 5;
ubyteb2=(bin[fByte + 1] 0xf8) 3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] 0x01) 6;
ubyteb2=(bin[fByte + 1] 0xfc) 2;
b~= (b1 | b2);
break;
default:
assert (false, This path should never be taken);
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit 7)
{fByte++;
fBit -=7;
}
}
}
Re: Adding days to std.datetime.Date
On Tuesday, December 02, 2014 14:14:58 Steven Schveighoffer via Digitalmars-d-learn wrote: On 12/2/14 2:00 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Tue, Dec 02, 2014 at 06:49:54PM +, via Digitalmars-d-learn wrote: But still, why this method http://dlang.org/phobos/std_datetime.html#.Date.add only supports month or years while this one http://dlang.org/phobos/std_datetime.html#.Date.roll does ? But still, why this method http://dlang.org/phobos/std_datetime.html#.Date.add only supports month or years while this one http://dlang.org/phobos/std_datetime.html#.Date.roll does support days ?* Hmm. Looks like an oversight. File a bug? Not an oversight. Date.add and Date.roll are for adding units that are variable. For example, how many days are in a month? Answer: depends on the month. How many days in a year? Answer: depends on the year. But days are NOT variable, there are exactly 24 hours in a day. So to add a day, you just add a day with +=. Exactly. add wouldn't even exist if it weren't for the fact that Duration doesn't work with units greater than weeks because of they depend on what date you're talking about. - Jonathan M Davis
Re: Adding days to std.datetime.Date
On Tuesday, December 02, 2014 14:21:35 Steven Schveighoffer via Digitalmars-d-learn wrote: On 12/2/14 2:14 PM, Steven Schveighoffer wrote: Not an oversight. Date.add and Date.roll are for adding units that are variable. For example, how many days are in a month? Answer: depends on the month. How many days in a year? Answer: depends on the year. But days are NOT variable, there are exactly 24 hours in a day. So to add a day, you just add a day with +=. Aaaand to expand on this, since roll *does* support days, it's because the number being added isn't the important unit, it's the unit above. Hence rolling days means you will stay in the same month. I'm not exactly sure of the reason behind roll, but I'm sure Jonathan has one :) A prime example of where to use it would be if you have a GUI with spinners for the values, and you didn't want incrementing the day to increment the month. It would be kind of annoying to implement that without roll. And since you need to specify the units for rolling (and the addition operator was already used for normal adding), adding a Duration to the time point in order to roll didn't make sense, and a separate function was needed for it even for the smaller units. I don't remember if roll originated with Boost, or if I came up with it though (since portions of std.datetime's API are based on Boost - e.g. julianDay is only there because Boost had it, and astronomers use it such that it seemed useful enough to have; I wouldn't have come up with it on my own though). - Jonathan M Davis
Accented Characters and Counting Syllables
Given the fact that static assert(é.length == 2); I was surprised that static assert(é.byCodeUnit.length == 2); static assert(é.byCodePoint.length == 2); Isn't there a way to iterate over accented characters (in my case UTF-8) in D? Or is this an inherent problem in Unicode? I need this in a syllable counting algorithm that needs to distinguish accented and non-accented variants of vowels. For example café (2 syllables) compared to babe (one syllable.
Re: repack ubyte[] to use only 7 bits
Charles Hixson:
byte[]x8to7 (ubyte[] bin)
Better to add some annotations, like pure, @safe, nothrow, if you
can, and to annotate the bin with an in.
intfByte, fBit;
It's probably better to define them as size_t.
switch (fBit)
I think D doesn't yet allow this switch to be _meaningfully_ a
final switch.
b=bin[fByte] 0x7f;
D allows binary number literals as 0b100110010101.
b~=(b1 | b2);
Perhaps an output range is better?
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit 7)
{fByte++;
fBit -=7;
The formatting seems a bit messy.
Bye,
bearophile
Re: Accented Characters and Counting Syllables
On Sat, Dec 06, 2014 at 10:37:17PM +, Nordlöw via Digitalmars-d-learn wrote: Given the fact that static assert(é.length == 2); I was surprised that static assert(é.byCodeUnit.length == 2); static assert(é.byCodePoint.length == 2); Isn't there a way to iterate over accented characters (in my case UTF-8) in D? Or is this an inherent problem in Unicode? I need this in a syllable counting algorithm that needs to distinguish accented and non-accented variants of vowels. For example café (2 syllables) compared to babe (one syllable. This is a Unicode issue. What you want is neither byCodeUnit nor byCodePoint, but byGrapheme. A grapheme is the Unicode equivalent of what lay people would call a character. A Unicode character (or more precisely, a code point) is not necessarily a complete grapheme, as your example above shows; it's just a numerical value that uniquely identifies an entry in the Unicode character database. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
Re: @property usage
On Thursday, December 04, 2014 10:21:10 uri via Digitalmars-d-learn wrote: Hi All, Do you guys use @property much, or is it largely ignored/avoided? @property is used rather freuently - e.g. some of the functions in the range API are required to be properties. Typically, @property is used when you'd use a getter or setter in another language (or when you need to emulate a variable). Using get* or set* would generally not be considered idiomatic D and is not typically done. @property functions are used instead. Now, because the parens are optional on functions with no arguments, there are plenty of cases where functions are called without parens when they're not properties, but property functions are quite common. - Jonathan M Davis
Re: Check type is a struct at compile time?
On Friday, December 05, 2014 20:38:30 Gary Willoughby via Digitalmars-d-learn
wrote:
How can i check that a type is a struct at compile time? I know i
can test for a class like this:
static if(is(T == class))
{
...
}
But how to do the same thing for a struct?
static if(is(T == struct))
{
}
- Jonathan M Davis
Re: @property usage
On Sat, 06 Dec 2014 15:23:10 -0800 Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Thursday, December 04, 2014 10:21:10 uri via Digitalmars-d-learn wrote: Hi All, Do you guys use @property much, or is it largely ignored/avoided? @property is used rather freuently - e.g. some of the functions in the range API are required to be properties. Typically, @property is used when you'd use a getter or setter in another language (or when you need to emulate a variable). Using get* or set* would generally not be considered idiomatic D and is not typically done. @property functions are used instead. Now, because the parens are optional on functions with no arguments, there are plenty of cases where functions are called without parens when they're not properties, but property functions are quite common. we all waiting for property enforcement fixes (which i already integrated, heh), so delegate properties can be used as propeties, omiting the annoying '()'. as this can break some invalid code (the code where people using properties as functions) i assume that we'll live with half-backed properties forever. signature.asc Description: PGP signature
Re: repack ubyte[] to use only 7 bits
Your comments would be reasonable if this were destined for a library,
but I haven't even finished checking it (and probably won't since I've
switched to a simple zero elimination scheme). But this is a bit
specialized for a library...a library should probably deal with
arbitrary ints from 8 to 64 or 128 [but I don't think that the 128 bit
type is yet standard, only reserved]. I just thought that something
like that should be available, possibly along the lines of Python's pack
and unpack, and wondered where it was and what it was called.)
Additionally, I'm clearly not the best person to write the library
version, as I still have LOTS of trouble with D templates. And I have
not successfully wrapped my mind around D ranges...which is odd, because
neither Ruby nor Python ranges give me much trouble. Perhaps its the syntax.
As for pure, @safe, and nothrow ... I'd like to understand that I
COULD use those annotations. (The in I agree should be applied. I
understand that one.)
As for size_t for indexes...here I think we disagree. It would be a bad
mistake to use an index that size. I even considered using short or
ushort, but I ran into a comment awhile back saying that one should
never use those for local variables. This *can't* be an efficient
enough way that it would be appropriate to use it for a huge array...but
that should probably be documented if it were for a library. (If I were
to use size_t indexing, I'd want to modify things so that I could feed
it a file as input, and that's taking it well away from what I was
building it for: converting input to a redis database so that I could
feed it raw serial data streams without first converting it into human
readable formats. I wanted to make everything ASCII-7 binary data,
which, when I thought about it more, was overkill. All I need to do is
eliminate internal zeros, since C handles various extended character
formats by ignoring them.
I'm not clear what you mean by a final switch. fBit must adopt
various different values during execution. If you mean it's the same as
a nest of if...else if ... statements, that's all I was really
expecting, but I thought switch was a bit more readable.
Binary literals would be more self-documenting, but would make the code
harder to read. If I'd though of them I might have used them...but
maybe not.
Output range? Here I'm not sure what you're suggesting, probably
because I don't understand D ranges.
The formatting got a bit messed up during pasting from the editor to the
mail message. I should have looked at it more carefully. My standard
says that unless the entire block is on a single line, the closing brace
should align with the opening brace. And I use tabs for spacing which
works quite well in the editor, but I *do* need to remember to convert
it to spaces before doing a cut and paste.
Thanks for your comments. I guess that means that there *isn't* a
standard function that does this.
Charles
On 12/06/2014 03:01 PM, bearophile via Digitalmars-d-learn wrote:
Charles Hixson:
byte[]x8to7 (ubyte[] bin)
Better to add some annotations, like pure, @safe, nothrow, if you can,
and to annotate the bin with an in.
intfByte, fBit;
It's probably better to define them as size_t.
switch (fBit)
I think D doesn't yet allow this switch to be _meaningfully_ a final
switch.
b=bin[fByte] 0x7f;
D allows binary number literals as 0b100110010101.
b~=(b1 | b2);
Perhaps an output range is better?
if(b == 0)bout~= 0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit 7)
{fByte++;
fBit -=7;
The formatting seems a bit messy.
Bye,
bearophile
[Issue 12736] @nogc std.algorithm.all
https://issues.dlang.org/show_bug.cgi?id=12736 sinkuup...@gmail.com changed: What|Removed |Added CC||sinkuup...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=13458 --
[Issue 13458] std.utf.decode not @nogc
https://issues.dlang.org/show_bug.cgi?id=13458 sinkuup...@gmail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=12736 --
[Issue 12742] @nogc std.algorithm.remove
https://issues.dlang.org/show_bug.cgi?id=12742 sinkuup...@gmail.com changed: What|Removed |Added CC||sinkuup...@gmail.com --- Comment #1 from sinkuup...@gmail.com --- Seems to work in DMD 2.066.0 or later. --
[Issue 12742] @nogc std.algorithm.remove
https://issues.dlang.org/show_bug.cgi?id=12742
--- Comment #2 from bearophile_h...@eml.cc ---
import std.algorithm: remove;
auto a = [1];
void main() @nogc {
a = a.remove(0);
}
dmd 2.067alpha:
test.d(4,17): Error: @nogc function 'D main' cannot call non-@nogc function
'std.algorithm.remove!(cast(SwapStrategy)2, int[], int).remove'
--
[Issue 12742] @nogc std.algorithm.remove
https://issues.dlang.org/show_bug.cgi?id=12742
--- Comment #3 from bearophile_h...@eml.cc ---
It's also not @safe:
import std.algorithm: remove, SwapStrategy;
struct Foo {}
void main() @safe {
Foo[] foos;
foos.remove!(x = true, SwapStrategy.unstable);
foos.remove!(x = true);
}
test.d(5,9): Error: safe function 'D main' cannot call system function
'test.main.remove!((x) = true, cast(SwapStrategy)0, Foo[]).remove'
test.d(6,9): Error: safe function 'D main' cannot call system function
'test.main.remove!((x) = true, cast(SwapStrategy)2, Foo[]).remove'
--
[Issue 12742] @nogc @safe std.algorithm.remove
https://issues.dlang.org/show_bug.cgi?id=12742 bearophile_h...@eml.cc changed: What|Removed |Added Summary|@nogc std.algorithm.remove |@nogc @safe ||std.algorithm.remove --
[Issue 10508] qsort_r is not present on older Linux systems
https://issues.dlang.org/show_bug.cgi?id=10508 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #3 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/druntime/pull/1059 --
[Issue 13766] std.container, std.range, std.regex documentation is now broken
https://issues.dlang.org/show_bug.cgi?id=13766 hst...@quickfur.ath.cx changed: What|Removed |Added Summary|std.range and std.regex |std.container, std.range, |documentation is now broken |std.regex documentation is ||now broken --- Comment #8 from hst...@quickfur.ath.cx --- Followup PR for std.container: https://github.com/D-Programming-Language/dlang.org/pull/717 --
[Issue 9691] Static void arrays are not documented
https://issues.dlang.org/show_bug.cgi?id=9691 --- Comment #10 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/a6f3dcc6df3edbe9f02e66f8a16b78ce1766c7c8 Merge pull request #716 from quickfur/issue9691b Better wording about difference between void[] and ubyte[]. --
