Re: D in accounting program
Hello tuanhoanganh, I am newbie of D language. I know D is new language. Is D v1.064 stable to write accounting application ( because ddbi is only support this D version).? Is there commercial write in D. D is stable enough to write accounting application if you consider it stable enough to write commercial software. There are many threads on that topic.
Re: blog: Overlooked Essentials for Optimizing Code
Hello Bruno, Which degree did 'Software engineers' take then? You know, that's one thing that kinda irks me: Why is it called 'Software engineers' when I've never seen engineering taught in a CS course (not to be confused with real "computer engineering" courses that are a lot more like EE than CS). The most direct example of this I know of is in "The Pragmatic Programmer": Item 18 is "estimate to avoid surprises" and then goes on to describe how to do that. Well, if programming were taught as an engineering discipline, that would be a pointless (if not insulting) comment because what it is advocating is so fundamental to engineering that it goes without saying.
Re: Interfacing C functions with safer ptr/length
Hello Walter, Walter Bright wrote: tls wrote: Walter is dead? I've been feeling much better lately. But I do have a peculiar hunger for brains now. Your a day to soon for that one.
Re: blog: Overlooked Essentials for Optimizing Code
Hello Bruno, On 31/10/2010 05:35, BCS wrote: Hello Bruno, Which degree did 'Software engineers' take then? You know, that's one thing that kinda irks me: Why is it called 'Software engineers' when I've never seen engineering taught in a CS course (not to be confused with real "computer engineering" courses that are a lot more like EE than CS). What are you referring to when you say "called 'Software engineers'" ? The people who write software, or the college degrees/programs? I didn't quite get it. I've never seen the details of a software engineering program so I can't say much on that, but my current job title is software engineer and I know *I'm* not doing engineering. The most direct example of this I know of is in "The Pragmatic Programmer": Item 18 is "estimate to avoid surprises" and then goes on to describe how to do that. Well, if programming were taught as an engineering discipline, that would be a pointless (if not insulting) comment because what it is advocating is so fundamental to engineering that it goes without saying. What do you mean "if programming were taught as an engineering discipline" ? I'm saying that programming is *not* taught or practiced as an engineering discipline (Ok, maybe the DOD, DOE and NASA do). Furthermore, I'm presenting the fact that "item 18" needs stating as evidence supported to support my assertion and supporting that with the assertion that any practitioner of an engineering discipline wouldn't need to be told about "item 18". To be totally clear, I'm not saying that software development should be done as an engineering process, but that the standard practices (and job title) of today shouldn't claim to be engineering.
Re: D/Objective-C Preliminary Design
Hello Michel, [o addObserver:self forKeyPath:@"window.frame" option:0 context:nil]; [...] Now imagine a whole program with functions like this one. Would you want to write a program like that? I know, not what you were saying but, err,.. No.
Re: The D Scripting Language
Hello Tomek, This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. The link from D seems dead to me (missing ':' after http).
Re: C header file importer using -J
Hello Peter, Would it be theoretically possible to use string mixins, CTFE, and import expressions (using the -J switch) to write a function cHeaderInclude such that it may be used like: mixin( cHeaderInclude( import( "someheader.h" ) ) ); I'm imagining that the cHeaderInclude function would parse the C code from the header, convert it to D declarations at compile time, and then returns those declarations to be mixed in, just like an #include would do. Preprocessor defines could be handled with extra parameters: "SOME_DEF=1, ANOTHER_DEF=foo" etc. Am I missing something that would make this impossible? That should be possible but would be highly complex. In effect you would need to implement a large chunk of a compiler. Given that there is already a tool to do that offline (http://www.digitalmars.com/d/2.0/htod.html) it would, IMHO, be inadvisable.
Re: Logical const
Hello Jordi, On 11/21/2010 02:43 AM, Michel Fortin wrote: On 2010-11-20 09:21:04 -0500, Peter Alexander said: D does not support logical const due to the weak guarantees that it provides. So, without logical const, how are D users supposed to provide lazy evaluation and memoization in their interfaces, given that the interface should *seem* const, e.g. [...] Using a static associative array as a cache will work: [...] I am also interested in what is the D way of doing this. The associative array approach is not suitable for the case of 4x4 matrices in a 3D application where you can have thousonds of them. At some point, the associative array lookup will be more expensive than the actual calculation. Cache eviction?
An opportunity to benchmark the DM back-end.
http://blog.regehr.org/archives/320 I ran across that post and started wondering: how hard would it be to get a version of DMC running on linux?
Re: (Improved) Benchmark for Phobos Sort Algorithm
Hello Craig, It was brought to my attention that the quick sort has a very bad worst case, so I implemented a simple fix for it. Now the worst case (completely ordered) is the best case, and it only slows down the general case by a small percentage. I thought to myself, "it can't be this easy to fix quick sort". Does anyone see a flaw in this simple fix? Performs much better than Phobos in completely random and completely sorted data. Perhaps there is another case where it doesn't do as well? I think I've seen it stated as: If you know the implementation, you can always generate a pathological case for QSort.
Re: RFC: SI Units facility for Phobos
Hello Andrei,
Benjamin Shropshire wrote an SI Units implementation which he refers
to here:
http://d.puremagic.com/issues/show_bug.cgi?id=3725
For convenience, here are direct links to the code:
http://www.dsource.org/projects/scrapple/browser/trunk/units/si2.d
http://www.dsource.org/projects/scrapple/browser/trunk/units/rational.
d
This cannot be considered a reviewable proposal yet because it doesn't
have sufficient documentation and is essentially in the stage where
Benjamin is asking for input on improving the design and
implementation.
Below are my comments in response to Benjamin's RFC. In brief, the
design is a bit off from what I hope to have an a units library, but
things can be fixed without too much difficulty by shuffling things
around.
* Call the library std.units and generally focus on units, not on SI
units.
* I suggest doing away with abstract unit names ("Distance", "Time",
"Mass" etc.) and use concrete plural units ("Meters", "Seconds",
"Kilograms" etc) instead. I agree that at a level operating with the
abstract names seems to be more pure, but at a concrete level you need
to have various reference points. For example, a molecular physics
program would want to operate with Angstroms, which should be a
distinct type from Meters.
Why would that be an improvement? The current system encode as length measurements
as meters but allows you to work with other units by converting at the point
that you convert a FP type to a united type. The issue I see with making
different units of length different types is that there is an unbounded set
of those and I don't see any reasonable way to allow encoding the conversion
structures for them.
If someone else is able to make such a library that is as clean as this one,
I'd not stand in its way, but I have no interest in writing such a beast.
* There should be ways to define scalars of distinct types and
relationships between them. For example, "Radians" and "Degrees"
should be distinct types, although both are scalar.
Ditto my comments for non-scalers on a smaller scale.
* The previous points bring me to an important design artifact: each
and every unit should have a multiplier (constant, template argument)
that describes its relationship to the SI corresponding entity. The SI
units themselves will have a 1.0 multiplier, and e.g. Angstroms has a
1e10 multiplier. The current library has a facility for that, but I
think that's not as good.
That sounds to me like what the library has so I must not be understanding
what you are asking for. Could you elaborate?
* In the proposed design the user can define a lot of distinct types,
such as Miles, Yards, and Lbs, which are strictly unnecessary
(Kilometers, Meters, and Kilograms could be used instead, with
appropriate I/O conversions to and from other units). I think offering
scale-less units chosen by the user is a good thing as long as there
is a unified mechanism for converting between those units without
risking confusion and bugs.
Again, that sounds to me like what the library does. All distance units are
of the same type and internally are encoded as meters, The rest of the units
are converted on access.
* There should be no implicit conversion to double and generally few
conversion smarts. The units should have a writable public field
"value".
* There should also be a property called siValue which yields the
value, converted to SI, of type double. For an Angstroms, siValue
returns value * 1e-10.
(Step-by-step on the code:)
* The code should use TypeTyple instead of T.
* I think FullSI should be always in effect. Even though many users
don't care for lumens and moles, they can just sit there defaulted at
the very end and shouldn't be bothersome.
That's my soap box protest to SI's (IMHO stupid) inclusion of them as base
units. :)
* Each artifact (extra, extra2, Batch...) should be documented.
Um, Yah. :o)
* I'm not sure about the use of fractional exponents. They add a fair
amount of complication. Could we dump them or use a simple fixed-point
scheme to accommodate them?
The only unit I know for sure has fractional exponents is in fracture mechanics
(kPa*m^0.5) but if you allow anything beyond that, any fixed-point scheme
I can think of would fall over right away (X^1/3?).
* The naming convention should consistently use NamesLikeThis for
types and namesLikeThis for values (including constants).
* A scheme similar to std.conv.to should serve as an all-around
converter, e.g. to!Kilometers(Miles(10)) should yield a value of type
Kilometers that contains 16.05 or whatever.
* All operators should be converted to D2 (yet another success story
of the new design :o)).
* Packages of remarkable constants would be nice to have, of course in
the appropriate units. The fields of astronomy, classical/relativistic
mechanics, electromagnetism, molecular physics, quantum mechanics,
come to mind.
All - please add your comments. Benjamin, I hope you're as
Re: RFC: SI Units facility for Phobos
Andrei Alexandrescu wrote:
> On 1/5/11 12:26 AM, BCS wrote:
> >> * I suggest doing away with abstract unit names ("Distance", "Time",
> >> "Mass" etc.) and use concrete plural units ("Meters", "Seconds",
> >> "Kilograms" etc) instead. I agree that at a level operating with the
> >> abstract names seems to be more pure, but at a concrete level you need
> >> to have various reference points. For example, a molecular physics
> >> program would want to operate with Angstroms, which should be a
> >> distinct type from Meters.
> >
> > Why would that be an improvement? The current system encode as length
> > measurements as meters but allows you to work with other units by
> > converting at the point that you convert a FP type to a united type. The
> > issue I see with making different units of length different types is
> > that there is an unbounded set of those and I don't see any reasonable
> > way to allow encoding the conversion structures for them.
> >
> It would be an improvement because there wouldn't be the need to
> multiply with a bias every time a value is assigned, with the
> corresponding loss in speed and precision.
> To exemplify, say a program wants to work in Angstroms. As all distances
> are stored in meters, ultimately all values stored and operated on would
> be very small, which adversely affects precision. At the other end of
> the scale, an astronomy program would want to work with light-years,
> which would force storage of large values as meters.
> To solve this issue, each unit may include a static multiplier that
> converts it to SI (e.g. meter), while at the same time allowing to store
> and operate directly on the unit of choice. So a program may actually
> store 10 Angstroms as the number 10, or 10 light-years as the number 10.
Ah. I see what you are getting at. OTOH I'm still not convinced it's any better.
A quick check shows that 1 light years = 9.4605284 ¡Ñ 10^25 angstroms. A mere
25 orders of magnitude differences, where IEEE754 doubles have a range of 307
orders of magnitude. As to the issue of where to do the conversions: I suspect
that the majority of computation will be between unit carrying types
(particularly if the library is used the way I'm intending it to be) and as
such, I expect that both performance and precision will benefit from having a
unified internal representation.
There /might/ be reason to have a very limited set of scaling factors (e.g.
atomic scale, human scale, astro scale) and define each of the other units from
one of them. but then you run into issues of what to do when you do
computations that involve more than one (for example, computing the resolution
of an X-ray telescope involves all three scales).
When I started writing the library, I looked at these issue just enough that I
knew sorting it wasn't going to be a fun project. So, rather than hash out
these issue my self, I copied as much as I could from the best units handling
tool I know of: MathCAD. As best I can tell, it uses the same setup I am.
> >> * There should be ways to define scalars of distinct types and
> >> relationships between them. For example, "Radians" and "Degrees"
> >> should be distinct types, although both are scalar.
> >
> > Ditto my comments for non-scalers on a smaller scale.
>
> The crux of the matter is that Radians and Degrees should be distinct
> types, and that a conversion should be defined taking one to the other.
> How can we express that in the current library, or what could be added
> to it to make that possible?
>
I don't think there /is/ a good solution to that problem because many of the
computations that result in radians naturally give scalar values
(arc-length/radius). As a result, the type system has no way to determine what
the correct type for the expression is without the user forcing a cast or the
like.
If angles are treated as an alias for scalar then the conversion to degrees can
be handled in a reasonable way (but that would also allow converting any scalar
value to degrees). I again punted on this one because people who have put more
time than I have available (MathCAD again) couldn't come up with anything
better.
> >> * In the proposed design the user can define a lot of distinct types,
> >> such as Miles, Yards, and Lbs, which are strictly unnecessary
> >> (Kilometers, Meters, and Kilograms could be used instead, with
> >> appropriate I/O conversions to and from other units). I think offering
> >> scale-less units chosen by the user is a good thing as long as there
> >> is a unified mechanism for converting between those
Re: RFC: SI Units facility for Phobos
In conclusion (yes I know this normally goes at the bottom) I think we are wanting different and contradictorily things from this library. Andrei Alexandrescu wrote: > On 1/5/11 10:32 AM, BCS wrote: > > Andrei Alexandrescu wrote: > [snip] > > Ah. I see what you are getting at. OTOH I'm still not convinced it's any > > better. > > > > A quick check shows that 1 light years = 9.4605284 ¡Ñ 10^25 > > angstroms. A mere 25 orders of magnitude differences, where IEEE754 > > doubles have a range of 307 orders of magnitude. As to the issue of > > where to do the conversions: I suspect that the majority of > > computation will be between unit carrying types (particularly if the > > library is used the way I'm intending it to be) and as such, I expect > > that both performance and precision will benefit from having a > > unified internal representation. > People might want to use float for compactness, which has range 1e38 or > so. But that's not necessarily the largest issue (see below). > > There /might/ be reason to have a very limited set of scaling factors > > (e.g. atomic scale, human scale, astro scale) and define each of the > > other units from one of them. but then you run into issues of what to > > do when you do computations that involve more than one (for example, > > computing the resolution of an X-ray telescope involves all three > > scales). > > There are two issues apart from scale. One, creeping errors due to > conversions. Someone working in miles would not like that after a few > calculations that look integral they get 67.998 miles. Second, let's > not forget the cost of implicit conversions to and from. The way I see > it, forcing an internal unit for representation has definite issues that > reduce its potential applicability. IMHO both of these are somewhat synthetic, that is they aren't significant issues in the real word. For the first, anyone who expects FP to give exact answers needs to learn more about FP. If you need exact answers, use an integer or rational type as your base type. As for the second point about perf; the usage mode I designed for will only perform conversions in I/O operations. Values are converted to Unit-bearing types at the first opportunity and remain there until the last possible moment. As such I expect that any operation that is doing more that a handful of conversions will be I/O bound not compute bound. > > When I started writing the library, I looked at these issue just > > enough that I knew sorting it wasn't going to be a fun project. So, > > rather than hash out these issue my self, I copied as much as I could > > from the best units handling tool I know of: MathCAD. As best I can > > tell, it uses the same setup I am. > I don't know MathCAD, but as far as I understand that's a system, not a > library, and as such might have a slightly different charter. In terms > of charter Boost units > (http://www.boost.org/doc/libs/1_38_0/doc/html/boost_units.html) is the > closest library to this. I haven't looked at it for a while, but indeed > it does address the issue of scale as I suggested: it allows people to > store numbers in their own units instead of forcing a specific unit. In > fact the library makes it a point to distinguish itself from an "SI" > library as early as its second page: > "While this library attempts to make simple dimensional computations > easy to code, it is in no way tied to any particular unit system (SI or > otherwise). Instead, it provides a highly flexible compile-time system > for dimensional analysis, supporting arbitrary collections of base > dimensions, rational powers of units, and explicit quantity conversions. > It accomplishes all of this via template metaprogramming techniques." > Like it or not, Boost units will be the yardstick against which anything > like it in D will be compared. I hope that D being a superior language > it will make it considerably easier to implement anything > metaprogramming-heavy. Reiterating my prior point, what I'm interested in developing is a library that handles the set of base physical units, of witch there is a know, finite set of base units and the derived units. You might be able to talk me into doing statically scaled units as distinct types but I'm not at all interested in allowing an arbitrary number of base units or in treating physicality equivalent units (e.g. feet and meters) to be considered as different base units. My unwillingness to go there is because I see very little value in doing a little of that (what other dimensions can be added that act like the SI base units?) and enormous cost in doing more of it (if you allow dim
Re: RFC: SI Units facility for Phobos
Andrei Alexandrescu wrote:
> On 1/5/11 4:06 PM, BCS wrote:
> > In conclusion (yes I know this normally goes at the bottom) I think
> > we are wanting different and contradictorily things from this
> > library.
> I almost didn't read the rest thinking that that's all you inserted.
> All: there's more, scroll down!
Oops. :o|
> One additional practical matter:
> > The way I would like that code to look would be:
> >
> > void computeFiringSolution(Radians angle)
> > {
> > auto s = angle.sin(); // only exist for Radians (and Scaler)
> > ...
> > auto newAngle = std.units.arcsin(s); // returns Radians
> > static assert(is(typeof(newAngle) : Radians));
> > }
> This is nice in theory but would have you essentially wrap by hand an
> unbounded number of functions. And for what? So they write angle.sin()
> instead of sin(angle.value).
There are very few general functions I know of that take units other than
scalers. As a result, I would expect that allowing scalers to implicitly
convert to floating point would cover most of those. And for the rest (sin,
etc.) there are few enough that adding them to the type may be practical.
For the non-general functions that do take non scaler values, I would think
explicitly asking for the value as a given unit (as the library currently does)
would be the better choice rather than having to convert it to the related type
for the unit and then asking for the values:
FnTakingMeters(Meter(length).value); // that could be redundant if length is
already meters...
FnTakingMeters(length.value); // but are you sure length it's already meters?
vs.
FnTakingMeters(length.meter); // gives length in meters.
> I appreciate the additional theoretical
> safety, but I don't see how that benefit compensates the cost. I want a
> practical library that allows me to work with libraries designed outside
> of it.
I agree on what but I'm not sure on how.
> Anyway, let's not forget that at the end of the day my opinion is one
> opinion and my vote is one vote. For the record, my vote is against the
> library in its current form for the following reasons:
> (a) Poor documentation
Um, Yeah. :o)
> (b) Limited expressiveness
In which way? Adding arbitrary base units? Things like Dynamic conversion
rates?
> (c) Numeric issues as I described (and no amount of rhetoric will set
> that straight; FWIW given the obvious question of scaling you need to
> prove it works, not me to prove it doesn't)
> (d) Unrealized potential (if we approve this, backward compatibility
> will prevent more comprehensive libraries having the same aim but a
> different design). This argument is to be taken with a grain of salt as
> in general it can be easily abused. What I'm saying is that once this
> library is in we may as well forget about scaled units a la boost units
> (which are the kind I'd want to use).
We have both said our piece on these, what do others think? I'd be particularly
interested in what Don has to say on the numeric issues. Does an extra layer or
two of FP rounding really mater.
Re: RFC: SI Units facility for Phobos
Jonathan M Davis wrote: > On Wednesday, January 05, 2011 15:40:37 BCS wrote: > > Andrei Alexandrescu wrote: > > > (c) Numeric issues as I described (and no amount of rhetoric will set > > > that straight; FWIW given the obvious question of scaling you need to > > > prove it works, not me to prove it doesn't) > > > (d) Unrealized potential (if we approve this, backward compatibility > > > will prevent more comprehensive libraries having the same aim but a > > > different design). This argument is to be taken with a grain of salt as > > > in general it can be easily abused. What I'm saying is that once this > > > library is in we may as well forget about scaled units a la boost units > > > (which are the kind I'd want to use). > > > > We have both said our piece on these, what do others think? I'd be > > particularly interested in what Don has to say on the numeric issues. Does > > an extra layer or two of FP rounding really mater. > > Personally, I tend to cringe when I see much in the way of floating points in > anything that needs precision, but it's not like you can avoid it in this > case. > Regardless, I agree with pretty much everything that Andrei has said. I > particularly don't like that the values are all in meters internal - > _especially_ when dealing with floating point values. I'd be very worried > about > precision issues. The Boost solution seems like a solid one me. However, I'm > not > likely the sort of person who's going to be using a unit library very often. > I > just don't deal with code that cares about that sort of thing very often. After a little more thinking I'm wondering if I'm targeting a different use case than other people are thinking about. The case I'm designing for, is where you have a relatively small number of inputs (that may be in a mishmash of units and systems), a relatively large number of computations and a relatively small number of outputs. The systems that Andrei is arguing for may be more desirable if there are relatively less computation (thus less internal rounding) or if all or most of the inputs are in a consistent system of units (resulting in very few necessary conversions). I'm primarily interested in the first use case because it is the kind of problem I have dealt with the most (particularly the mishmash of units bit) and for that, the two proposals are almost equivalent from a perf and accuracy standpoint because each should convert the inputs to a consistent system, do all the math in it, and then convert to the output units (I'm not even assuming the outputs form a consistent system). The only difference is that the current arrangement picks the consistent system for you where the alternative allows (and forces) you to select it.
Re: D Issue Tracking System
Hello Robert, On 2011-01-09 11:44:05 +0100, Jérôme M. Berger said: Is not it more or less a standard bugzilla [1] install? Really? Hmm... ok. Nevermind. I normally don't like bugzilla that much. Maybe this is a case where the defaults are right and the tweaks stink...
Re: syntax definition language
On 10/23/2011 04:58 AM, Gor Gyolchanyan wrote: Hi, guys! Can anyone tell me what's the name of this syntax definition language, used here: http://www.d-programming-language.org/lex.htm ? You might find this interesting: http://dsource.org/projects/scrapple/browser/trunk/dparser It's way out of date, I never completely finished it and it can't handle the D grammar as documented (b/c of standard left recursion problem) but ...
Re: GSoC Mentor Summit Observations and D Marketing
On 10/24/2011 08:19 PM, Walter Bright wrote: On 10/24/2011 6:52 PM, Brad Roberts wrote: On Mon, 24 Oct 2011, Walter Bright wrote: A pitch needs to be longer and more informative. You've got 20-30 seconds to convince the person to look deeper. It's enough to list a couple important points. Top three reasons it's worth looking at closer.. something along those lines. The 3 keys come next. It has to be more than two, and less than 4. I've been toying with: 1. control 2. multi-paradigm 3. robustness (Yes, I've been reading a book on this!) 1. uncompromising performance. 2. maximum utility. 3. no unnecessary complexity.
Re: Ada, HCSS and more
On 10/25/2011 08:16 PM, bearophile wrote: (Report after a mistake.) This looks mostly like Ada advertisement, but it's readable (May 2008): http://www.mil-embedded.com/articles/id/?3277 The Reddit thread about it: http://www.reddit.com/r/programming/comments/lol4l/ccjava_a_gazillion_features_and_still_suck_at/ From the article: Last year's High Confidence Software and Systems (HCSS) conference, sponsored by NSA to address security-critical issues, featured an interesting presentation from Microsoft addressing such issues in the context of Windows. The primary sources of problems in Microsoft's experience are buffer overruns and integer overflow problems.< I have done some searching, but I have not found this presentation. Bye, bearophile Regarding integer overflow problems: http://blog.regehr.org/archives/598 It would be interesting to run DMD/DMC through his integer checking tool: http://embed.cs.utah.edu/ioc/
Re: Early std.crypto
On 10/24/2011 05:10 PM, Piotr Szturmaj wrote: https://github.com/pszturmaj/phobos/tree/master/std/crypto This is some early work on std.crypto proposal. Currently only MD5, HMAC and all SHA family functions (excluding SHA0 which is very old, broken and no longer in use). I plan to add other crypto primitives later. I know about one SHA1 pull request optimized for SSSE3. I think native code must be there to support other non x86 CPUs and SIMD optimization may be added at any time later. Any opinions are welcome. Especially if such design is good or bad, and what needs to be changed. Thanks :) Are you re-implementing the function kernels your self or are you using an existing implementation? Given what I've heard about things like side-channel attacks using processing times to recover keys, I'd rather not see Phobos use anything written by less than the best expert available.
Re: goto [variable], and address of code labels
On 10/28/2011 09:30 AM, Manu wrote:
Hi people.
I'd like to propose support for taking the address of code labels, and
supporting variable goto statements.
This is a feature I have found extremely useful, implemented as a GCC
specific extension.
I've used this to get great speedups and simplify code while writing
emulators/vm's. Perhaps also useful in efficient state machine type code
too...
Simple example:
void *opcodes[] = { &OP_ADDA, &OP_SUBA, &OP_MOVA, &OP_JMPA, &OP_etc... };
void exec()
{
// begin execution
goto opcodes[ pProgram[regs.PC++] ];
OP_ADDA:
regs.A += pProgram[regs.PC++];
goto opcodes[ pProgram[regs.PC++] ];
OP_SUBA:
regs.A -= pProgram[regs.PC++];
goto opcodes[ ];
OP_MOVA:
regs.A = pProgram[regs.PC++];
goto opcodes[ pProgram[regs.PC++] ];
OP_JMPA:
regs.PC = regs.A;
goto opcodes[ pProgram[regs.PC++] ];
OP_etc:
...
goto opcodes[ pProgram[PC++] ];
}
Notice how this structure completely eliminates branch logic, control
statements, etc.
Note, GCC code labels are void*, but in D, perhaps some special code
label pointer type should be invented for type safety...
One may also expect that function pointers may also be implicitly cast
to this generalised code pointer type, which might be useful in some
code where a naked function pointer is used to implement some custom
calling convention.
For the given example, this could be re-cases via a switch statement
that ends each case with a "goto case pProgram[regs.PC++];". That is
assuming non-const expression are allowed as the expression. The end
result should be identical.
Re: The D players
On 10/30/2011 09:00 PM, Walter Bright wrote: On 10/30/2011 11:18 AM, Steve Teale wrote: who is Stalin? "One pointer bug is a tragedy. A million pointer bugs is a statistic." - Joseph Ceelin. "Are you laboring under the impression that I can compile this code of yours? I can't even open the file." - Franklin D. Rubysvelt "Now I want you to remember that no programmer ever made an app work by following best practices. He made it work by making the other poor dumb programmer work his ass off." - George S. Phppon "The inherent vice of static typing is the unequal sharing of bugs; the inherent virtue of dynamic typing is the equal sharing of crashes." - Winston C#arphill Nice :-D
Re: static try?
On 11/01/2011 10:04 AM, kenji hara wrote:
--1;
It you want to reduce duplication of long code, you can use string mixin.
enum code = q{ ...long code... };
static if (is(typeof({ mixin(code); })))
{
mixin(code);
}
else
{
...
}
Please no! I've thought for years that string mixins are seriously
overused in D. IMnsHO they should only be used as a method of last
resort. For every case I've seen where there is a alternative to a
string mixin, the alternative was cleaner.
If people don't like the static try/catch, how about: static try/else?
Kenji Hara
2011/10/31 Mehrdad:
I've written this piece of code a fair number of times:
static if (is(typeof(foo( { foo(); }
else { bar(); }
When the expression inside the condition (i.e. the call to foo()) gets
complicated, you get lots of code duplication and things become harder to
read.
So I'm thinking, why not just introduce a 'static try'?
Something like:
static try
{
foo();
}
catch // (string ex) // perhaps let them know what the error is?
{
bar();
}
It's a clean and immensely readable improvement IMO, and it doesn't
introduce any new keywords or any breaking changes to anything.
How's the idea?
Re: static try?
On 11/02/2011 12:24 AM, Don wrote:
On 02.11.2011 03:57, bcs wrote:
On 11/01/2011 10:04 AM, kenji hara wrote:
--1;
It you want to reduce duplication of long code, you can use string
mixin.
enum code = q{ ...long code... };
static if (is(typeof({ mixin(code); })))
{
mixin(code);
}
else
{
...
}
Please no! I've thought for years that string mixins are seriously
overused in D. IMnsHO they should only be used as a method of last
resort. For every case I've seen where there is a alternative to a
string mixin, the alternative was cleaner.
If people don't like the static try/catch, how about: static try/else?
Probably worth noting that in the latest release, you can instantiate a
template from inside an is(typeof()), and if it fails to compile, the
template instantiation will be discarded. (Prior to 2.056, if the
template instantiation failed, compilation would fail).
This means you can now factor out "does it compile?" tests into a
template, to reduce code duplication.
That still has the (potential) issue of putting the code out-of-line.
Re: More bugs found in OS code
On 11/02/2011 09:00 PM, Adam D. Ruppe wrote: bearophile: But how many times do you want to ignore some of the arguments listed? I do a lot. The way I do it is the arguments are made available to the format, but it doesn't always need them at runtime. string f = showNames ? "%1$s\t%2$d" : "%2$d"; writefln(f, name, number); Though I don't literally use writefln for most my code the same idea applies. If you use a literal format string, don't use indexed formatting and don't use all the args, I think it would be safe to call that a bug in most any case. Fail any one of those pre-conditions and you may have a point.
Re: Early std.crypto
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote: bcs wrote: Are you re-implementing the function kernels your self or are you using an existing implementation? Given what I've heard about things like side-channel attacks using processing times to recover keys, I'd rather not see Phobos use anything written by less than the best expert available. Until now, I implemented some hash functions. There are no branching instructions in their transform() routines, so theoretically processing time is independent of the function input. From my very incomplete memory I found the source I was looking for (I googled for "aes interperative dance") here http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html Look for "Foot-Shooting Prevention Agreement" in one of the images ~20-25% of the way down. tl;dr; It mentions "cache-based, timing, and other side channel attacks". Unless you can explain to me what those are, in painful detail, I don't think we should trust you to avoid them. Get a good vetted C implementation and wrap it with a nice D API and call it a day.
Re: DMD workforce contribution
On 11/07/2011 04:33 AM, Steven Schveighoffer wrote: On Mon, 07 Nov 2011 04:51:57 -0500, Walter Bright wrote: On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote: I'm not quite familiar with DMD's internals, so the best answer would be "whatever is more important to do". I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned on. Add test cases to cover dmd source code that is not tested. 4. There are many static analyzers on the market. Try compiling dmd with one or more of them, and propose fixes. 5. Go through the Bugzilla unresolved issues, pick what interests you, and propose patches to fix them. 6. Investigate popular benchmarks (such as the "shootout"). Compare the native code generated by dmd with that of C or C++, and identify inefficient code sequences. 7. Install NetBSD or OpenBSD, and port dmd to them. 9. (8 was already spoken for :) Improve DDOC. This might actually be a good way to learn how the code is represented internally (speaking from complete ignorance). 9+n: Improve the documentation? -Steve
Re: assert(obj) is an atrocity
On 11/08/2011 04:28 PM, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge. I would have used assert(!!obj) because it's shorter.
Re: assert(obj) is an atrocity
On 11/08/2011 11:42 PM, Timon Gehr wrote: On 11/09/2011 04:52 AM, bcs wrote: On 11/08/2011 04:28 PM, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge. I would have used assert(!!obj) because it's shorter. If you have already typed 'assert(obj', it is not shorter. Faster to type? No. Shorter? Yes it still is. I spend enough more time reading and thinking about code that size is more relevant then typing speed.
Re: Bartosz about Chapel
On 11/11/2011 10:47 AM, Walter Bright wrote: On 11/11/2011 4:37 AM, Nick Sabalausky wrote: In my school experience (both high school and college), the students who were well versed in and heavily focused on rote regurgitation were consistently the ones with the best grades, and the ones who where therefore considered to be "smart" even though they couldn't have reasoned to save their lives. That *needs* to change. That was true of my high school, but not my college (Caltech). At Caltech, rote memorization would get you precisely nowhere. Exams were (by institute policy) open book and open note. This did have the interesting effect of forcing the profs to come up with exams that could not be completed by rote. I came to attend Caltech mostly by accident, and it was a most fortunate accident. The attitude and culture of Caltech suited my personality almost perfectly. (For another example, professors were not allowed to take attendance at lectures, not allowed to make attendance part of the grade, not allowed to proctor exams (100% honor system), etc. I loved being treated like an adult for the first time.) One might ask, isn't it easy to cheat under such a system? Yes, it is. But such a system had an unexpected effect. The students did not regard themselves as the adversaries of the professors. The students liked the honor system so much that if someone did cheat, they'd get ostracized. Ostracism is a powerful and very effective means of getting conformance. Almost nobody cheated (to my knowledge). The/a solution to the cheating problem at anything but the last set of classes is to make the next set of classes *painful* to take if you don't know the materiel from the prerequisite. The point of the class after all is to teach you the materiel (whatever that amounts to) and if you've got the materiel how you got there is irrelevant. That all depends however on a carefully tuned definition of "got the materiel".
Re: [OT] Re: Bartosz about Chapel
On 11/11/2011 12:26 PM, Daniel Gibson wrote: Am 11.11.2011 19:54, schrieb Ali Çehreli: On 11/11/2011 09:56 AM, Daniel Gibson wrote: > (Also none-ascii chars in code outside of strings is bad IMHO) In English code, right? :) There are real problems of using the ASCII relatives of Turkish letters: döndür: return dondur: freeze dön: turn don: underwear sık: squeeze sik: (a four-letter word) Thousands more... :) Ali I (almost?) always use english variables, classnames etc, even though it's not my native tongue. And if I, for whatever reason, use non-english names I still stick to ascii. I just image that someone else will want to understand or modify my code and he may not speak my language Why do you assume they will know English? and may not have umlauts and stuff like that on his keyboard. Good point. As I said, this does not apply to strings that are displayed to the user, obviously.
Re: [OT] Re: Bartosz about Chapel
On 11/13/2011 12:07 PM, Daniel Gibson wrote: Am 12.11.2011 18:20, schrieb bcs: On 11/11/2011 12:26 PM, Daniel Gibson wrote: Am 11.11.2011 19:54, schrieb Ali Çehreli: On 11/11/2011 09:56 AM, Daniel Gibson wrote: > (Also none-ascii chars in code outside of strings is bad IMHO) In English code, right? :) There are real problems of using the ASCII relatives of Turkish letters: döndür: return dondur: freeze dön: turn don: underwear sık: squeeze sik: (a four-letter word) Thousands more... :) Ali I (almost?) always use english variables, classnames etc, even though it's not my native tongue. And if I, for whatever reason, use non-english names I still stick to ascii. I just image that someone else will want to understand or modify my code and he may not speak my language Why do you assume they will know English? It's taught in schools all over the world and almost anybody who programs can at least read english (you're screwed otherwise because documentation of languages and (standard-) libs, and the classes etc in libraries themselves are usually in english). Cheers, - Daniel I've sat near conversations that were clearly in a language I didn't know and where the subject at hand was just as easy to identify. You get into a technical field and every third word is Geek no matter what the other two are. I want to put a sketch in a move: two professors walk into a room, have a 10 minute heated argument about something and *then* notice they don't have any natural language in common.
Re: Continuous Merging For GDC and LDC?
On 11/15/2011 03:40 PM, Iain Buclaw wrote: On 15 November 2011 23:21, dsimcha wrote: How does the merging process for new Phobos/druntime/DMD front ends work w.r.t. GDC and LDC? To what extent is it automated? If it's mostly automated except when things go wrong (or could be made so), we should set up a server somewhere (maybe on one of the DMD tester boxes that's underworked, if there is one) that automatically merges every commit to druntime/phobos/dmd and tests it. It seems to take agonizingly long after every DMD release for LDC and GDC to get caught up, which makes sense only if the merges are being done by hand or changes are made to low-level stuff (certain parts of druntime, the glue layer of the compiler, etc.). Furthermore, such continuous merging might encourage DMD/Phobos/druntime devs to do things in a more LDC/GDC-friendly way and would make trunk revisions of Phobos/druntime/dmd in between releases available to GDC/LDC users. API changes in the D frontend could break builds. New features in D that require backend support could break builds. The only positive to continuous merging is that they will be caught early and dealt with. Other than that, I tend to use merges as a time to start merging in some experimental features I've got in the flux. In this current merge I've been working out support for named value return support in gdc, and weeding out some bugs present in the current in/out contract inheritance. It seems to me that there would be some value in this proposal. If nothing else it could start with the most up-to-date hand merged instance is available, branch (is that the correct term?) from it, go as far as it can from that and generate a pull request for the maintainers to consider. If it can merge cleanly from the DMD trunk and the test situation doesn't regress, It's likely correct (and if it isn't then the test suite is lacking :) and if it's not correct, it has likely done a lot of the boring work. Having that available would provide something like "nightly" builds to the people who want that and it would provide as much automation as the maintainers want to get from it (after all, it would be madness to allow such a system to actual muck with the official branch).
Re: newsgroup web viewer
On 11/15/2011 06:51 PM, Adam D. Ruppe wrote: I've complained about the godawful web viewers for the newsgroup before, and wrote a little program to do a better job. But, I got distracted and didn't quite finish it. I didn't like how it looked primarily. Today, I dropped it into the skeleton of d-programming-language.org and now I pretty much like how it looks: http://arsdnet.net/d-web-site/nntp/get-thread?newsgroup=digitalmars.D&messageId=%3Cj9ps5n%2430nq%241%40digitalmars.com%3E&ordering=ByDate My goal is to present the newsgroup in a more web forum like way, so it's more comfortable to more users. Is there a lot of interest in this kind of thing among the community? Very bluntly, the most noticeable difference (aside from pure style issues) is that you have included the think I **HATE** the most about Web Forums: You have completely obscured the structure of the news groups. News group (and e-mail) threads have a strong hierarchy to them that contains a significant about of information that I use when viewing things. As one example, when skimming threads, I often only look at sub trees that involve particular authors. With your layout, this sort of information is utterly lost. It would be hard to overstate the strength of my option on this subject. Given the option, I would use a crappy, slow, feature poor thick client that does a half asses job of presenting hierarchy over virtual any client, no matter how well done, that doesn't.
Re: newsgroup web viewer
On 11/15/2011 08:38 PM, bcs wrote: On 11/15/2011 06:51 PM, Adam D. Ruppe wrote: I've complained about the godawful web viewers for the newsgroup before, and wrote a little program to do a better job. But, I got distracted and didn't quite finish it. I didn't like how it looked primarily. Today, I dropped it into the skeleton of d-programming-language.org and now I pretty much like how it looks: http://arsdnet.net/d-web-site/nntp/get-thread?newsgroup=digitalmars.D&messageId=%3Cj9ps5n%2430nq%241%40digitalmars.com%3E&ordering=ByDate My goal is to present the newsgroup in a more web forum like way, so it's more comfortable to more users. Is there a lot of interest in this kind of thing among the community? Very bluntly, the most noticeable difference (aside from pure style issues) is that you have included the think I **HATE** the most about Web Forums: You have completely obscured the structure of the news groups. News group (and e-mail) threads have a strong hierarchy to them that contains a significant about of information that I use when viewing things. As one example, when skimming threads, I often only look at sub trees that involve particular authors. With your layout, this sort of information is utterly lost. It would be hard to overstate the strength of my option on this subject. Given the option, I would use a crappy, slow, feature poor thick client that does a half asses job of presenting hierarchy over virtual any client, no matter how well done, that doesn't. Aside from that, looks nice.
Re: newsgroup web viewer
On 11/15/2011 07:18 PM, Adam D. Ruppe wrote: Trass3r Wrote: http://www.digitalmars.com/webnews/newsgroups.php is nicer and works fine for me the few times I need a web viewer. Oh, I keep forgetting this one exists! Can we get this linked from the main newsgroups page at least? A threaded view is a must have :) Change the ordering to ByParent in the url, though I haven't adjusted the stylesheet to include proper spacing for that. Either that's not working, it's not what I want or the stylesheet thing is getting in the way. It puzzles me how people actually like that view though! I hate threaded views with a passion. Do you actually enjoy having to guess what something is in reply to? Or how about the fun you can have trying to locate replies to a given post? Or what about when one branch of a thread goes off on a interesting tangent and another dives down a rabbit hole you couldn't care less about? Unless you plan on reading *everything* (and when things get interesting, that is just flat impossible, even if you don't have a job), the most important information is virtually invisible in anything but a threaded view.
Re: newsgroup web viewer
On 11/15/2011 08:45 PM, Adam D. Ruppe wrote: bcs Wrote: You have completely obscured the structure of the news groups. You can change the view to see it in email ordering, or descending parent ordering. I don't want ordering, I want a tree. Which I mentioned in a subthread, but you probably didn't see it Correct because that strong hierarchy separates the content into branches Yup of a tree where things get lost, fractured, and difficult to follow, instead of a sane, linear view where the conversations flow naturally. You must have miss-spoke. I assume your intended to say organised and grouped instead of an insane interleaved view where the conversation's natural structure is mashed flat and destroyed. /j (The truth is I just hadn't finished reading the thread. Even if I had, I would have said more or less the same thing just in replay to a different post. Oh wait, that would have looked the same to you.) Hmmm. I'm going to have to remember when replying to you to trim the quoted sections as much as possible so that the maximum amount of the content is encoded in the ancestry of my posts.
Re: newsgroup web viewer
On 11/15/2011 09:03 PM, Adam D. Ruppe wrote: bcs Wrote: Either that's not working, it's not what I want or the stylesheet thing is getting in the way. Stylesheet... did a quick adjustment, try now: http://arsdnet.net/d-web-site/nntp/get-thread?newsgroup=digitalmars.D&messageId=%3Cj9ps5n%2430nq%241%40digitalmars.com%3E&ordering=ByParent Cut the tab size by about 60% and that's usable. OTOH it will still end up with a column size of -10 pt about the time threads get interesting. Do you actually enjoy having to guess what something is in reply to? There's no guesswork at all. People quote what they are replying to when it matters, like you and I are doing now. And if anyone keeps more than about 3 layers of quoting you need to be Tolstoy to be more than half the content. And it still doesn't solve the problem because it's still not the original full message. Or how about the fun you can have trying to locate replies to a given post? On the other hand, finding new posts is virtually impossible with a tree view, because it's mixed in at random. Nope, finding them is trivial. I hit the N key or look for the bold titles. Admittedly, a bit harder to do in a web interface than a "real" client. Or what about when one branch of a thread goes off on a interesting tangent and another dives down a rabbit hole you couldn't care less about? This might be an idea to put into the UI. All the parent information is there, so it could zap a subthread out of view instantly, regardless of view mode.
Re: newsgroup web viewer
On 11/15/2011 09:12 PM, Adam D. Ruppe wrote: bcs Wrote: You must have miss-spoke. I assume your intended to say organised and grouped instead of an insane interleaved view where the conversation's natural structure is mashed flat and destroyed. I've *never* had a conversation in real life where time branched out. That's one of the advantage of NNTP over talking. The closest you can come in real life is if a group splinters, and instead of a public forum, you have a bunch of private conversations that just happen to take place in the same room. Yup and with news groups you can read them in whatever order you want, consider them independently and even response (clearly and explicitly) to a specific comment at any time after it was made. Oh wait, that would have looked the same to you.) Yeah. I use the email gateway for reading, and skim posts in real time as they arrive in my inbox (which can be sorted in a variety of ways, but I usually keep it on strict linear, oldest first.) It's pretty rare that I look at the in-reply-to header at all. It serves almost no purpose. It's pretty rare that I look at the time header at all. It serves almost no purpose. Most claims you can make to support a tree view being useless I can tweak slightly to make support a tree view being the better solution. I say we paint the bike shed grey.
Re: newsgroup web viewer
On 11/15/2011 09:54 PM, Andrei Alexandrescu wrote: On 11/15/11 8:38 PM, bcs wrote: On 11/15/2011 06:51 PM, Adam D. Ruppe wrote: I've complained about the godawful web viewers for the newsgroup before, and wrote a little program to do a better job. But, I got distracted and didn't quite finish it. I didn't like how it looked primarily. Today, I dropped it into the skeleton of d-programming-language.org and now I pretty much like how it looks: http://arsdnet.net/d-web-site/nntp/get-thread?newsgroup=digitalmars.D&messageId=%3Cj9ps5n%2430nq%241%40digitalmars.com%3E&ordering=ByDate My goal is to present the newsgroup in a more web forum like way, so it's more comfortable to more users. Is there a lot of interest in this kind of thing among the community? Very bluntly, the most noticeable difference (aside from pure style issues) is that you have included the think I **HATE** the most about Web Forums: You have completely obscured the structure of the news groups. No need to worry about that. Only digitalmars.D.announce posts will be there, and there's little structure to them. Essentially we want to publish just announcements. I don't need to worry about it until NNTP access is shut off. The only time I use a web interface is when I don't have access to my own system.
Re: newsgroup web viewer
On 11/16/2011 08:04 AM, Adam Ruppe wrote: bcs Wrote: Cut the tab size by about 60% and that's usable. OK OTOH it will still end up with a column size of -10 pt about the time threads get interesting. Another fundamentally broken aspect of tree views. Not inherently. That is a fundamentally broken aspect of placing the messages bodies in-line with a tree views. And if anyone keeps more than about 3 layers of quoting you need to be Tolstoy to be more than half the content. Well, the way I see it, if you're quoting more than two lines at a time, you're probably over-quoting. Exactly. Remember, in both linear and tree views, getting back to the parent post is very easy, How? I don't see any back links? and if someone is reading the reply, it is likely that he read the parent already anyway. Only true for me about 40-50% of the time: "So-n-so responded to this sub tree so there might be something interesting in it, so I will start reading there." I hit the N key or look for the bold titles. How is that N key implemented? boldEach(find!"a.timestamp> b"(sort!"a.timestamp< b.timestamp") (messages)); or something like that. I don't really know, but I assume thunder-bird stores a bit somewhere for each post indicating what I've opened. Anything based on time stamp would be useless as I very rarely read thread in time order.
Re: newsgroup web viewer
On 11/16/2011 07:23 PM, Adam D. Ruppe wrote: Jesse Phillips Wrote: How is that easy in a linear, err chronological, view? The parent isn't the one directly above. Hit a View Parent link. http://arsdnet.net/d-web-site/nntp/get-message?newsgroup=digitalmars.D&messageId=%3Cj9v9k7%241lji%241%40digitalmars.com%3E digitalmars.D Thread: newsgroup web viewer by Adam D. Ruppe In reply to: Re: newsgroup web viewer by Walter Bright Add that to the multi post view with it pointing to an anchor on the same page and you might have a point. Added bonus: instant caching.
Re: newsgroup web viewer
On 11/16/2011 10:14 AM, Walter Bright wrote: I really do not understand why people keep writing replacements for newsreaders that miss fundamentally useful aspects of it. Because they have never used a proper new reader?
Re: newsgroup web viewer
On 11/16/2011 07:53 AM, Adam Ruppe wrote: But looking at a tree thread is almost impossible once it gets to more than about ten posts without computer assistance, and even then, it's so fractured that people repeat themselves a lot. I find I have that tendency no matter what the format. If, in a thread, there are more than about 20 post I haven't read, I tend to just not read anything that isn't in response to something I posted. Linear, hierarchical. Doesn't matter much. At least with hierarchical I sometimes read the siblings of my posts. I think it's a defensive time management tactic. I've seen threads here that literally grew content faster than I cold read it (assuming I wanted to think about it at all).
Re: newsgroup web viewer
On 11/16/2011 08:46 PM, Kagamin wrote: bcs Wrote: On 11/16/2011 10:14 AM, Walter Bright wrote: I really do not understand why people keep writing replacements for newsreaders that miss fundamentally useful aspects of it. Because they have never used a proper new reader? What do you do if you don't have access to your proper newsreader, but have access to internet? Well you should be able to find feature list and screen shots from the available options. Anyone who is going to make an effort to write a NNTP client should really try out the existing one first. For that matter, most anyone who has the resources to write a new client will have the resources to run an old one.
Re: newsgroup web viewer
On 11/17/2011 05:04 AM, Kagamin wrote: bcs Wrote: Well you should be able to find feature list and screen shots from the available options. Anyone who is going to make an effort to write a NNTP client should really try out the existing one first. For that matter, most anyone who has the resources to write a new client will have the resources to run an old one. legacy newsreaders are so suboptimal, that nobody considers to run them While I haven't found any that are Jump up and down squealing good, some of the ones that are available are quite good. The origonal statement was that some of the *new* clients are total crud because they fail to even attempt to use some of the features that make NNTP such an enduring thing; e.g. clients that try and make a news group into a php forum.
Re: newsgroup web viewer
On 11/17/2011 09:02 PM, Adam D. Ruppe wrote: Walter Bright Wrote: 1. compact, threaded view You have to acknowledge that a lot of people don't see this as newsgroups getting it right. And you have to acknowledge that a significant of people do see this as getting it right. And because Walter is in that group, the official community device will support tree type threads. I'm completely opposed to it. (recursive*) Threaded views aren't just suboptimal. They are a *bad* thing. It was progress to ditch that misfeature, and it pains me that so many people want it anyway. * Simple threads can be good. Some organization helps. Too much is bad. If they are suboptimal and bad, how do you then explain that the most prolific form of electronic communication has a model that is almost identical to NNTP? http://xkcd.com/802/ When you get right down to it, from the client perspective, NNTP is just a world readable e-mail address.
Re: newsgroup web viewer
On 11/18/2011 06:06 AM, Adam D. Ruppe wrote: bcs Wrote: And you have to acknowledge that a significant of people do see this as getting it right. That's why I've had a [Tree] link in the program since almost the beginning. If they are suboptimal and bad, how do you then explain that the most prolific form of electronic communication has a model that is almost identical to NNTP? Very few people use email sub-threads. Most emails are individual things that come into your box linearly. I rarely see sub threads used even in mailing lists. Other email threads are one level deep threads. This is the only view a lot of popular clients even bother supporting. Weather or not a particular e-mail client chooses to present e-mails as a tree like structure, the medium its self has a tree like structure. (this does bring up something - my emails are marked as read individually. They are unread based on time, but read based on being open with an individual flag in the message. So I was wrong about that before.)
Re: Early std.crypto
On 11/20/2011 08:10 AM, Piotr Szturmaj wrote: bcs wrote: On 11/04/2011 04:27 AM, Piotr Szturmaj wrote: bcs wrote: Are you re-implementing the function kernels your self or are you using an existing implementation? Given what I've heard about things like side-channel attacks using processing times to recover keys, I'd rather not see Phobos use anything written by less than the best expert available. Until now, I implemented some hash functions. There are no branching instructions in their transform() routines, so theoretically processing time is independent of the function input. From my very incomplete memory I found the source I was looking for (I googled for "aes interperative dance") here http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html Look for "Foot-Shooting Prevention Agreement" in one of the images ~20-25% of the way down. tl;dr; It mentions "cache-based, timing, and other side channel attacks". Unless you can explain to me what those are, in painful detail, I don't think we should trust you to avoid them. Get a good vetted C implementation and wrap it with a nice D API and call it a day. > Sorry for late answer. Np, but I still have a number of concerns: What is the advantage to implementing the kernels of any of these functions in D? Will the code be faster? Smaller? More secure? More maintainable? (On the other hand, the value of doing the API code in D goes with no debate.) How many people in the D community have the experience and know-how to review the security of an implementation? If there are less than 2 or 3 people who can do that, can we afford to include native kernels? We can't have just one and if we have only two and one leaves for some reason the code becomes un-maintainable for lack of a reviewer. *I* wouldn't be comfortable with less than about 4-5. I didn't implement AES yet, but it can be implemented without lookup tables (countermeasure to cache-timing attacks). Branch-free code without secret-data dependent memory accesses is free from cache-timing vurnelabilities on most architectures. The remaining are architectures where instruction execution times (cycles) may depend on data (f.i. multiply by 0 may take 1 cycle, and >2 cycles when multiplying by other numbers). I don't know any concrete examples but I realize such cycle-varying instructions _may_ exist. Of course such instructions must be avoided in secure code. The most hard to avoid side channel attack is Power Analysis. On almost all CPUs instruction power drain depends on the operands. Again multiplying by 0 consume less power than multiplying by other numbers and that may be distinguished on the oscilloscope. There are some countermeasures including operand blinding, but not all crypto algorithms support that. I only implemented some hashing functions: MD5, SHA1/224/256/384/512 and Tiger1/2. MD5 and SHA have code that is branch-free and does not use any data dependent lookups so their execution time should be constant, making timing attacks harmless. Unfortunately Tiger function does lookups based on the source bytes and is vurnelable to cache-timing attacks. This may be considered insecure and removed (openssl does not support it either) as making it secure may be not worth it. The only problem that remain is the power analysis which require physical access to the computer. We need to ask ourselfs to what degree we must secure our code. I'm going to argue that no single implementation is secure to power analysis on all architectures. I think we must stick to cache/branch timing level and forget about power analysis as its scope is beyond D's specification. We simply can't avoid most power analysis attacks because most of the countermeasures belong to the hardware instead of the software level.
Re: Early std.crypto
On 11/22/2011 08:16 AM, Piotr Szturmaj wrote: bcs wrote: How many people in the D community have the experience and know-how to review the security of an implementation? If there are less than 2 or 3 people who can do that, can we afford to include native kernels? We can't have just one and if we have only two and one leaves for some reason the code becomes un-maintainable for lack of a reviewer. *I* wouldn't be comfortable with less than about 4-5. I know Regan Heath who wrote some crypto code for Tango. Also, I suspect that D _will_ gain more (crypto) contributors, especially after joining GCC. "Wrote some crypto code" is a rather weak recommendation. Depending on how you interpret it, that would recommend *me*. A better recommendation would be "Mr Y gets paid by security company X to do crypto analysis" or "Mrs Z has published several well review papers on vulnerabilities in this kind of code". Minimum number of contributors/reviewers requirement in open-source project is at least unfortunate in my opinion. Nevertheless, I respect your thoughts. But imagine what could happen if Walter waited for contributors instead of starting D project on his own? Please realize that we do not implement every possible crypto algorithm at once. We need to start with something like hashing, then add encryption and other cryptographic primitives. I have no problem with that comment. My concern revolves around the point that the implementation of cryptographic primitives has security implications. I'm worried that we don't have the resources to demonstrate that our implementation is at least as good as the currently available implementation. I'd rather Phobos not include a given primitive than contain one of unknown quality. What I'd like to see is that the crypto package quickly contain interfaces for all the primitives we can find pre-vetted Boost licensed implementations for. At that point I would have no issue with as methodical and meticulous effort to divest ourselves of external dependencies as we can get access to the expertises needed to vet our own implementations (to the same level as the code they are replacing). Yes, I'm intentionally being paranoid here but this is security and paranoia is part of the job description darn-it.
Re: Early std.crypto
On 11/26/2011 04:19 PM, Brad Anderson wrote: How about putting a disclaimer on the module warning the code hasn't been through a rigorous security audit and point them at well established C libraries if they need that sort of assurance. What does that gain over implementing the first itteration in terms of well established C libraries and then replacing that with native implementations as the code goes been through a rigorous security audit? Or how about do both as API compatible implementations? That would work for people who need the proven security and people who can't afford external dependencies as well as allow them to be swapped out for each other with minimal effort once the native code is proven.
Re: Early std.crypto
On 11/27/2011 12:14 PM, Brad Anderson wrote: That's even better but isn't the issue over bundling incompatibly licensed libraries with phobos? Nothing is stopping someone from writing bindings for these libraries as some random library on D Source or Github already. If we can't find something with a licence allowing bundling then we just include the D language bits (including bindings) and note that along with where to get the lib. An agreed upon API would be very nice in any case. That is necessary (or at least very desirable) in any case as it would allow swapping one cipher for another just as easily as it would allow swapping one implementation for another.
Re: Early std.crypto
On 11/27/2011 12:15 PM, Piotr Szturmaj wrote: Jude Young wrote: On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote: On 11/26/2011 04:19 PM, Brad Anderson wrote: How about putting a disclaimer on the module warning the code hasn't been through a rigorous security audit and point them at well established C libraries if they need that sort of assurance. What does that gain over implementing the first itteration in terms of well established C libraries and then replacing that with native implementations as the code goes been through a rigorous security audit? Or how about do both as API compatible implementations? That would work for people who need the proven security and people who can't afford external dependencies as well as allow them to be swapped out for each other with minimal effort once the native code is proven. I do like this idea. swap implementations by simply swapping import and linking? nice. This was my goal... to write native implementation along with OpenSSL wrapper and add 'useOpenSSL' version identifier. Would that satisfy everyone? Yes, though I'd prefer to see them distinct and non-mutually exclusive. For one things, someone may well consider the native implementation of one primitive vetted before they consider another to be. Both results could be had by the suitable application of aliases.
Re: A real Forum for D
On 11/29/2011 10:52 AM, Jonathan M Davis wrote: On Tuesday, November 29, 2011 08:58:59 Sean Kelly wrote: The iPhone news reader is passable but not great. I can't do usenet from work though (firewall) so I've long since moved to using Brad's email forwarder. With IMAP that keeps everything in sync across machines too. Too bad most email clients don't do the tree threaded view. Kmail does (which is what I use), and I'm pretty sure that Thunderbird does. But a tree-view is definitely a must for a decent e-mail client IMHO. I've definitely found that IMAP is the way to go though, since it syncs the view across machines, and I don't know how to get that with a newsgroup client even if it works at both work and home (and wherever else you'd need to sync). - Jonathan M Davis Given the similarity of e-mail and NNTP post, I wonder what it would take to make an IMAP/NNTP bridge that allow any email client to be used as an NNTP client.
Re: Is D more cryptic than C++?
On 11/30/2011 03:36 AM, Abrahm wrote: "Adam Wilson" wrote in message news:op.v5q2zgji707...@invictus.skynet.com... In my experience D is roughly analogous to C# in terms of crypticness and readability, I am here doing long-term evaluations of D as a replacement for C# on my employers projects as we may face power constraints in the future that preclude the use of a JIT'ed language. So far, I like what I've seen. But I thought that C# could be precompiled in some fashion? In either case, going from C# to D seems like a major move. Not so much the move but a too broadly defined application that it could actually be a good fit with both languages. A while back I built a tool to do automatic translation of C# to D1. Aside from a small number of language features, a large number of libraries and a significant amount of freedom w.r.t. formatting, the darn thing worked! (Debugging it was "fun", as in running diffs of million+ line execution traces. But then I'm crazy enough to do that!) Up shot is that for some applications, those languages aren't really that different.
Re: Is D more cryptic than C++?
On 11/30/2011 08:47 PM, Abrahm wrote: "bcs" wrote in message A while back I built a tool to do automatic translation of C# to D1. Oh, so you prefer the easy tasks then! Noted. (Embedded sarcasm defined: Try going from D to C#! A very much harder, end of the chapter excercise). The direction was not by choice, we had a C# code base a need to run on Linux and a good reason to not us Mono. Aside from a small number of language features, a large number of libraries and a significant amount of freedom w.r.t. formatting, the darn thing worked! Well, don't make it out to be an accomplishment of the "harder" end-of-chapter excercises when it is actually in the easy section. I never claimed that it was complex! In fact I, my point is better supported by it being simple. (Debugging it was "fun", as in running diffs of million+ line execution traces. But then I'm crazy enough to do that!) Your need for "praise" and whatever, noted. I can't help you with that (not that I don't want to or that your need isn't an indicator of something wrong). I'm not bragging, Even if I was, the only thing I could brag about there would be bull-headedness. It would sort of be like you bragging about how hard it is to find adjective that describe you that are usable in polite company. Up shot is that for some applications, those languages aren't really that different. That's really good. You're well on your way to completing the coursework. Gold star. Keep up the good work. You *really* have zero idea what my point is don't you?
Re: Is D more cryptic than C++?
On 12/01/2011 08:02 AM, Timon Gehr wrote: On 12/01/2011 06:34 AM, bcs wrote: On 11/30/2011 08:47 PM, Abrahm wrote: "bcs" wrote in message A while back I built a tool to do automatic translation of C# to D1. Oh, so you prefer the easy tasks then! Noted. (Embedded sarcasm defined: Try going from D to C#! A very much harder, end of the chapter excercise). The direction was not by choice, we had a C# code base a need to run on Linux and a good reason to not us Mono. Nice! =D. How well does the resulting C#-style D code perform? I don't recall if we ever ran per test. I do remember that wasn't a huge amount slower. I'm also not sure we ever finished it, but if not, it was for lack of resources not any technical constraint.
Re: Is D more cryptic than C++?
On 11/30/2011 08:32 PM, Abrahm wrote: "Jesse Phillips" wrote in message news:jb6qfv$1kut$1...@digitalmars.com... What bearophile was referring to was the use of templates is common. Are you sure about that? What say you Bear? D's templates have the advantage of being easier on the eyes and more powerful (with the inclusion of 'static if' in the language). Having "come from" C++land, and knowing what some people do with it, making it EASIER to apply templates does not seem necessarily a good thing to me. (Ref: template metaprogramming). That said, does your statement above about D's template machinery being "powerful" etc., mean "it's easier to do template metaprogramming in D"? If so, I, personally, do not find that any asset at all (though I know some surely will, for there have been books written on that "abhorrence"). Most of the argument for template metaprogramming being a bad thing in C++ are just flat not valid in D. That is not by chance. While designing the D template system they (including the guy who wrote one of these books you mention) took as look at what people actually want to do with all that abhorrence and provided a sane way to do it. With one 10th the complexity, D can do 10 times as much. As a specific example, one of the most abhorrent bits of D template code I've worked with is a compile time parser generate that, at compile time, parses a string into an AST describing the grammar that it will then generate a recursive decent parser to parse. All in under 1-2kLOC. Version 2 was going to include the ability to automatically reactor out left recursion so that it could handle the D grammar as documented. Even at the level of complexity, it wasn't really that hard to comprehend. The same end effect is available in C++ but takes a megabyte and a half of header files.
Re: ow Integers Should Work
On 12/05/2011 05:31 AM, bearophile wrote: Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support): http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642 I've been following that guy for a while now. He's doing some REALLY nifty work with regards to automating processing regarding bugs. Bye, bearophile
Re: ow Integers Should Work
On 12/05/2011 08:37 AM, Don wrote: On 05.12.2011 14:31, bearophile wrote: Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support): http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642 Bye, bearophile Not very convincing, since he proposes a change to existing architectures, and seems completely unaware of the overflow flag. I think he's looking at it form the language theory standpoint. As such, architectures has nothing to do with it (the architectures to be targeted has yet to be defined at that point) and getting access to the overflow flag would require exposing it natively in the language. If you can change existing architectures, why not simply allow an exception to be generated if an overflow occurs? Doesn't seem at all helpful to D.
Re: ow Integers Should Work
On 12/05/2011 01:37 PM, Don wrote: On 05.12.2011 18:36, bearophile wrote: Manu: Also, contrary to his claim, I find that wrapping is usually what I DO want in this case.. It's super rare that I write any code that pushes the limits of an int (unless we're talking 8-16 bit, see my range+saturation comment before), and when I do write code that pushes the range of an int, I can't think of a time when I've not wanted to wrap as expected. The code you usually write seems rather unusual. I have kind of the opposite situations. But first of all, "trapping" ints are needed to avoid bugs in normal code. Some bugs are shown here: http://embed.cs.utah.edu/ioc/ Those mostly aren't relevant for D. C has many cases of undefined behaviour because it doesn't require twos-complement arithmetic. D doesn't have that problem. We still need to tidy up the semantics of << and >> to remove undefined behaviour. But it's hard to do much more than that. The "overflow12.pdf" paper on that site shows statistics that overflow is very often intentional. It's strong evidence that you *cannot* make signed overflow an error. Even if you could do it with zero complexity and zero performance impact, it would be wrong. What is needed is a type that has *defined* overflow characteristics (IIRC unsigned does but there might be value in having a signed one as well) and, maybe, another one that traps. Undefined overflow is a bugs waiting to happen: // In C for (short i = 1; i > 0; i++); Under GCC, no optimisation finishes in ms. With -O9, it's an endless loop.
Re: ow Integers Should Work
On 12/06/2011 09:49 AM, Walter Bright wrote: On 12/6/2011 9:14 AM, Andrei Alexandrescu wrote: Translating dtoa.c to D and making sure it works during compilation sounds like a great project. People who want to help D in any way, please take notice :o). Sadly, despite dtoa.c's wide use, there doesn't appear to be a test suite for it. I suppose we could email David Gay and ask. Fuzz test it? Feed it and the clone random data (after a archive of selected values) until they give different results or you get sick of waiting.
Re: ow Integers Should Work
On 12/05/2011 11:20 PM, Don wrote: On 06.12.2011 05:21, bcs wrote: On 12/05/2011 08:37 AM, Don wrote: On 05.12.2011 14:31, bearophile wrote: Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support): http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642 Bye, bearophile Not very convincing, since he proposes a change to existing architectures, and seems completely unaware of the overflow flag. I think he's looking at it form the language theory standpoint. As such, architectures has nothing to do with it (the architectures to be targeted has yet to be defined at that point)and getting access to the overflow flag would require exposing it natively in the language. It's not that he hasn't specified an architecture. It's a proposal which does not work on _any_ existing architectures! It's pure fantasy. Well you can do it on x86. The fact the it doesn't provied hardware traps is irrelevant. You might need to add a lot of branches but you can get the semantics he is asking for. That said, there is another interesting (but independent) question of can it be done efficiently? You might have a very good question there, but that isn't the question regehr is considering. And he talks about NaN, when he means infinity. Floating point overflow never results in a NaN. You have a point there. He doesn't seem to know anything about saturating integer arithmetic, which exists in hardware (even x86 machines have supported a couple of operations since 1996). Useless. Again, he's not interested in the hardware implementation, he's only interested in the defined semantics of the language, the things you can count on regardless of that instruction set you are using. The fact the x86 has saturating integer operations is moot because C doesn't have a type the end up using them.
Re: ow Integers Should Work
On 12/06/2011 11:50 PM, Don wrote: He's talking about system languages. A system language has to have a close relationship to the architecture. By contrast, if you don't care about performance, it's easy -- just use BigInts for everything. Problem solved. Looks like I have to put it more bluntly: I don't think he knows what he's talking about. (On this particular topic). I know exactly what you have been saying I just think you are wrong, not because I don't think you knows what you are talking about but because I think you are evaluating his conclusion based on a different criteria than he is. More specifically, I think we are dealing with a differing order of priories for system languages. Mine would put safety (i.e. NO undefined behaviour) over performance. I think he is going the same way. Personally, if I could only have one, I think I'd (first) go with defining overflow semantics rather than trapping but I'm not sure which is more useful in a systems context. Can we at least agree that if you are only going to have one signed integer semantic, that undefined overflow is the worst possible choice?
Re: Comma operator = broken design
On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote: I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed. Furthermore, this operator makes it very hard to introduce Python-style tuples in the language. IIRC the generated code argument was actually made with regards to the compiler doing internal rewriting of the AST. If I'm remembering correctly, this make it even weaker as, at that point, there is no reason that the form of the AST need match the syntax.
Re: ow Integers Should Work
On 12/08/2011 04:15 AM, Don wrote: On 08.12.2011 05:46, bcs wrote: On 12/06/2011 11:50 PM, Don wrote: He's talking about system languages. A system language has to have a close relationship to the architecture. By contrast, if you don't care about performance, it's easy -- just use BigInts for everything. Problem solved. Looks like I have to put it more bluntly: I don't think he knows what he's talking about. (On this particular topic). I know exactly what you have been saying I just think you are wrong, not because I don't think you knows what you are talking about but because I think you are evaluating his conclusion based on a different criteria than he is. HE PROPOSES CHANGING INSTRUCTION SETS. [citation needed] I just re-scanned both posts. The closest thing I found to suggesting that instruction sets be changed is proposing iNaN be used and that (if you scan futher up) is listed as one possibility (late trapping) along side another (early trapping) that (if you scan even further up) isn't even being suggested for every operation but only for non-intermediate values. More specifically, I think we are dealing with a differing order of priories for system languages. Mine would put safety (i.e. NO undefined behaviour) over performance. I think he is going the same way. Personally, if I could only have one, I think I'd (first) go with defining overflow semantics rather than trapping but I'm not sure which is more useful in a systems context. Can we at least agree that if you are only going to have one signed integer semantic, that undefined overflow is the worst possible choice? Yes, but D doesn't have undefined overflow. So it's irrelevant. I'm not talking about D. Well, not directly anyway. So that irrelevant. And I think we have concluded that there isn't a single bit of this back and forth that we both care about.
Re: Some standard protocols in Phobos
On 12/12/2011 04:55 AM, bearophile wrote: I think it will eventually become important to have some standard protocols in Phobos, like one for images like this: http://www.python.org/dev/peps/pep-0368/ Do you like? and similar ones for: - matrices - basic 2D pixel-oriented graphics. - basic database usage Bye, bearophile Likely the easiest way to ram that in in would be to pick one, design an interface, implement 3-5 concrete examples and submit a pull request. I.e. create a de-facto standard. I think there is already one in the works for DBs .
Re: Some standard protocols in Phobos
On 12/12/2011 08:17 PM, Jonathan M Davis wrote: On Monday, December 12, 2011 20:07:37 bcs wrote: On 12/12/2011 04:55 AM, bearophile wrote: I think it will eventually become important to have some standard protocols in Phobos, like one for images like this: http://www.python.org/dev/peps/pep-0368/ Do you like? and similar ones for: - matrices - basic 2D pixel-oriented graphics. - basic database usage Bye, bearophile Likely the easiest way to ram that in in would be to pick one, design an interface, implement 3-5 concrete examples and submit a pull request. I.e. create a de-facto standard. I think there is already one in the works for DBs . A pull request would not be sufficient. Any major additions to Phobos must go through a review process on the newsgroup and be voted into Phobos. Pull requests are generally for smaller additions and bug fixes rather than whole new modules and the like. So, unless you're talking about just a function or two here, then this kind of stuff is likely to require a formal review. OK, so maybe I over simplified a bit and omitted to mention some of the later steps. :b That being said, the main way to get this kind of stuff into Phobos is to just buckle down and do it. If you're the first to come up with a new piece of functionality and are willing to work it through the review process, then you can get stuff added that way. If you sit around, hoping that someone else will do it, it may never happen. Let me clarify what I was trying to say: What he said. :o)
Re: Some standard protocols in Phobos
On 12/12/2011 11:13 PM, bearophile wrote: Brad Roberts: The best way to get something done is to do it. I think the point of view about your opinion differers across different nations of the world. That POV leads to results like: http://delight.sourceforge.net/ Before doing things some people want to discuss if it's a good idea, and to know if others are interested in its results/consequences. True, but that will happen any way before a pull request gets blessed. And if the package doesn't pass muster, you can still publish it somewhere else.
Re: Some standard protocols in Phobos
On 12/13/2011 06:46 PM, Jesse Phillips wrote: On Mon, 12 Dec 2011 20:07:37 -0800, bcs wrote: Likely the easiest way to ram that in in would be to pick one, design an interface, implement 3-5 concrete examples and submit a pull request. I.e. create a de-facto standard. I think there is already one in the works for DBs . Haha, it is good to know your audience. I was going to make a similar statement, but saw bearophile had made the post. Know is involvement in the community I realized he wasn't asking to get these in, but as he says poll for interest and opinions. For such I don't really have much to comment. The only one of those I can really understand what it would mean to have a standard protocol for is the DB. The others, I'm not sure what it is solving that isn't addressed by actually having it in Phobos (Why not have matrices and not just their protocol?). "Sequential" data is to ranges as matrices are to what?
Re: ACCU and D
On 01/03/2012 02:46 AM, Russel Winder wrote: My proposal for a talk at ACCU 2012 showing that D and Go prove that the C++11 standard may well be the eulogy for C++ has been accepted. http://accu.org/index.php/conferences/accu_conference_2012/accu2012_sessions#Go, D, C++ and the Multicore revolution. Welcome to the Jungle. If you are in Oxford 2012-04-24 to 2012-04-28 feel free to come to the conference. This year there is much more of a C++ and Java feel to it, probably due to C++11 and Java 7. More hecklers required :-) http://accu.org/index.php/conferences/accu_conference_2012
Re: ACCU and D
On 01/03/2012 11:29 PM, Nick Sabalausky wrote: "bcs" wrote in message news:je0pl8$218s$1...@digitalmars.com... On 01/03/2012 02:46 AM, Russel Winder wrote: My proposal for a talk at ACCU 2012 showing that D and Go prove that the C++11 standard may well be the eulogy for C++ has been accepted. http://accu.org/index.php/conferences/accu_conference_2012/accu2012_sessions#Go, D, C++ and the Multicore revolution. Welcome to the Jungle. D's got fun 'n games, D's got everything you want... Well that works to... http://herbsutter.com/2011/12/29/welcome-to-the-jungle/
Re: The God Language
On 12/29/2011 02:15 AM, Caligo wrote: This is somewhat of a serious question: If there is a God (I'm not saying there isn't, and I'm not saying there is), what language would he choose to create the universe? It would be hard for us mortals to imagine, but would it resemble a functional programming language more or something else? And what type of hardware would the code run on? I mean, there are computations happening all around us, e.g., when an apple falls or planets circle the sun, etc, so what's performing all the computation? I have two contradictory answers: Languages, Prolog. Hardware, something that can solve the hauling problem (but just for for turning machines).
Re: Welcome to the Jungle (article about the future of parallel computing)
On 01/06/2012 11:08 PM, Nick Sabalausky wrote: "Paulo Pinto" wrote in message news:je7vvh$253f$1...@digitalmars.com... > Hi, > > I just saw a follow up article from Herb Sutter about > the future of parallel computing. > > http://herbsutter.com/welcome-to-the-jungle/ > > Very interesting read. Excuse me if someone has already > posted it. > It is interesting...But I have to say: The*one* thing that really bugs me about it is that it seems to be written under the assumption that the highest-end hardware that's*sitting around on store shelves* is the only hardware that's relevant, or even exists. I think the thought is that *in the long run* the only chips that will hang around fall into one of two sets: The most powerful chips available and the most power efficient chips available. When you are buying new, why would you get anything else? In the short term there will be older stuff around but firstly, "nobody" buys used and secondly it's going to get replaced at some point (if for no other reason but getting damaged by handling). As a second rebuttal, I think the article is directed squarely at the "My program needs to run faster (lets throw hardware at it)!" crowd.
Re: Apparently unsigned types really are necessary
On 01/21/2012 10:05 PM, Walter Bright wrote:
http://news.ycombinator.com/item?id=3495283
and getting rid of unsigned types is not the solution to signed/unsigned
issues.
A quote from that link:
"There are many use cases for data types that behave like pure bit
strings with no concept of sign."
Why not recast the concept of unsigned integers as "bit vectors (that
happen to implement arithmetic)"? I've seen several sources claim that
uint (and friends) should never be used unless you are using it for low
level bit tricks and the like.
Rename them bits{8,16,32,64} and make the current names aliases.
Re: Apparently unsigned types really are necessary
On 01/22/2012 01:31 AM, Marco Leise wrote:
Am 22.01.2012, 08:23 Uhr, schrieb bcs :
On 01/21/2012 10:05 PM, Walter Bright wrote:
http://news.ycombinator.com/item?id=3495283
and getting rid of unsigned types is not the solution to signed/unsigned
issues.
A quote from that link:
"There are many use cases for data types that behave like pure bit
strings with no concept of sign."
Why not recast the concept of unsigned integers as "bit vectors (that
happen to implement arithmetic)"? I've seen several sources claim that
uint (and friends) should never be used unless you are using it for
low level bit tricks and the like.
Those are heretics.
Rename them bits{8,16,32,64} and make the current names aliases.
So everyone uses int, and we get messages like: "This program currently
uses -1404024 bytes of RAM". I have strong feelings against using signed
types for variables that are ever going to only hold positive numbers,
especially when it comes to sizes and lengths.
OK, I'll grant that there are a (*extremely* limited) number of cases
where you actually need the full range of an unsigned integers type. I'm
not suggesting that the actual semantics of the type be modified and it
would still be usable for exactly that sort of cases. My suggestion is
that the naming be modified to avoid suggesting that the *primary* use
for the type is for non negative numbers.
To support that position, if you really expect to encounter and thus
need to correctly handle numbers between 2^31 and 2^32 (or 63/64, etc.)
then you already need to be doing careful analyses to avoid bugs from
overflow. At that point, you are already considering low level details
and using a "bit vector" type as a number is not much more complicated.
The added bonus is that the mismatch between the name and what it's used
for is a big red flag saying "be careful or this is likely to cause bugs".
Getting people to think of it that way is likely to prevent more bugs
that it cause.
Re: Apparently unsigned types really are necessary
On 01/22/2012 10:09 AM, Walter Bright wrote: On 1/22/2012 4:40 AM, Marco Leise wrote: Or is this like spaces vs. tabs? 'Cause I'm also a tab user. I struggled with that for years. Not with my own code, the tabs worked fine. The trouble was when collaborating with other people, who insisted on using tab stop settings that were the evil spawn of satan. Hence, collaborated code was always a mess. Like newklear combat toe to toe with the roosskies, the only way to win is to not play. The only way to win the whitespace war is to change the rules: My I propose the following modifications to the D lexer: ''' White space may consist of: - A comment between any two tokens. - A single space between tokens that, if adjoined would be a single token. All other white space (including \n \r \t \v, etc.) is forbidden and a lexical error. ''' With these additions, all valid D code will be so hard to read that nobody will ever attempt to read it without first running a re-formatter over it and once that is standard practice, everyone will see it in there own preferred style.
Re: Apparently unsigned types really are necessary
On 01/22/2012 01:42 AM, Mail Mantis wrote: 2012/1/22 Walter Bright: http://news.ycombinator.com/item?id=3495283 and getting rid of unsigned types is not the solution to signed/unsigned issues. Would it be sane to add integer overflow/carry runtime checks in -debug builds? This could probably solve such issues, but we'd need some means to avoid this checks when nesessary. http://embed.cs.utah.edu/ioc/
Re: [OT] Programming language WATs
On 01/20/2012 07:40 AM, Robert Clipsham wrote:
Just came across this amusing 4 minute video:
https://www.destroyallsoftware.com/talks/wat
Anyone have any other WATs you can do in other languages? Bonus points
for WATs you can do in D.
IIRC:
int i, j = getInt();
for (switch(j) {
case 0: i = 5; break;
case 1: i = 4; break;
default: i = 42; } i < 77; i++)
writefln("Wat!?");
Re: [OT] Programming language WATs
On 01/22/2012 12:49 PM, Matt Soucy wrote:
On 01/22/2012 03:24 PM, bcs wrote:
On 01/20/2012 07:40 AM, Robert Clipsham wrote:
Just came across this amusing 4 minute video:
https://www.destroyallsoftware.com/talks/wat
Anyone have any other WATs you can do in other languages? Bonus points
for WATs you can do in D.
IIRC:
int i, j = getInt();
for (switch(j) {
case 0: i = 5; break;
case 1: i = 4; break;
default: i = 42; } i < 77; i++)
writefln("Wat!?");
Wat.
This managed to confuse me and most of the people around me. Especially
since it works.
http://www.d-programming-language.org/statement.html#ForStatement
Everything from after the '(' up to and including the first ';' is
defined by use of an NoScopeNonEmptyStatement or ';' (the first happens
to include variable decelerations, expression statements and
if/for/switch/etc.).
Re: Apparently unsigned types really are necessary
On 01/22/2012 01:24 PM, Era Scarecrow wrote:
My I propose the following modifications to the D lexer:
'''
White space may consist of:
- A comment between any two tokens.
- A single space between tokens that, if adjoined would be a
single token.
All other white space (including \n \r \t \v, etc.) is
forbidden and a lexical error.
'''
With these additions, all valid D code will be so hard to read that
nobody will ever attempt to read it without first running a re-formatter
over it and once that is standard practice, everyone will see it in
there own preferred style.
'\n' would be a invalid white space? Wow I see problems with that. Take a
following debugging function of mine. Uses combination spaces, newlines and
tabs. I think it's easy to read and understand.
//(incomplete without the full class/struct, but you get the idea)
void print() {
writeln("\nP.empty = ", empty,
"\nP.front = ", front,
"\nP.position = ", position,
"\nP.cap = ", cap,
"\nP.map = ", map, "\n");
}
That would instead becomes
void print() {
writeln("\nP.empty = ", empty, "\nP.front = ", front, "\nP.position = ", position, "\nP.cap =
", cap, "\nP.map = ", map, "\n");
}
Far more likely the rules would have to be set for the editor to convert
tabs into specific number of spaces and save it as such (and convert them back
if they want). Otherwise in said projects, enforce certain rules for the
project regarding formatting and reject it otherwise until they fix it.
Points:
1) that 2nd formatting still includes whitesapce that would be illegal
(e.g. every place but between 'void' and 'print' and in the strings
litereals).
2) The *point* is to turn code into an unreadable mash on a single line.
3) The entire proposal is satire.
Re: Apparently unsigned types really are necessary
On 01/23/2012 07:13 PM, Era Scarecrow wrote: From: "Nick Sabalausky" ''' White space may consist of: - A comment between any two tokens. - A single space between tokens that, if adjoined would be a single token. All other white space (including \n \r \t \v, etc.) is forbidden and a lexical error. ''' With these additions, all valid D code will be so hard to read that nobody will ever attempt to read it without first running a re-formatter over it and once that is standard practice, everyone will see it in there own preferred style. Hah! I like it :) It does have a certain amount of sense it makes... but if that were really an issue, then having your won formatter strip the unneeded spaces and then re-introducing them back seems trivial, in which case a indentation tool would be more likely to be used (GNU indent anyone?). It does however become an issue regarding debugging, if sources are compiled against said compacted sources in that way. Everything would be on line 1, and other such messes. Course if your compiling the sources yourself and run it through your formatter your fine. But if someone else has their own format and download the source and reformat it to their format, line 117 may not point to anything, or point to the wrong object, or worse yet, if an assert was thrown and it was an unrelated passing assert; that is with the assumption you use a program compiled with debugging flags and you don't rebuild said executable. And most importantly of all. I quote "If it ain't broke, don't fix it". That's just a tools problem... :b
Re: A modest proposal
On 01/23/2012 06:10 PM, Walter Bright wrote: On 1/23/2012 5:57 PM, Brad Anderson wrote: I understand some people like bug closures and who am I to judge but there is a limit to what some of us can tolerate and it has been surpassed. I live to make IRC users suffer. It's dessert after eating babies. How appropriate, considering the title.
Re: Apparently unsigned types really are necessary
On 01/23/2012 02:11 AM, Marco Leise wrote:
Am 23.01.2012, 00:22 Uhr, schrieb Era Scarecrow :
Points:
1) that 2nd formatting still includes whitespace that would
be illegal
(e.g. every place but between 'void' and 'print' and in the
strings
litereals).
2) The *point* is to turn code into an unreadable mash on a
single line.
3) The entire proposal is satire.
Ahh, i had the impression from the list that all whitespace tokens
were referring to a single statement line, not as a whole.
Guess the only way to make it so spaces (1 or more) were whitespace,
would be if we still use a fixed 80character width screen for our
editors, then leftover whitespace becomes formatting. But it seems
sufficiently stupid to do that, filesize being the largest part.
I know all of C appeared in it's formatting, to allow you to drop all
whitespace (with minor exceptions) into a single line, which is why
/**/ comments were used and c++'s // ones were added later. Although
fun to do a whole lot on a single line, i don't know if i would want to.
/*C code following the follow proposal; tested and works. Not bad for
165 characters of pure code.*/ isprime(int n){int cnt=2;if(n<2)return
0;for(;cnt
Sorry, but you still have unnecessary spaces in 3 places ;)
4, the space between the leading comment and 'isprime' must be removed
as well.
Re: dmd makefile dependencies
On 01/24/2012 05:50 PM, Daniel Murphy wrote: I assume you mean the windows one? dmc is fast enough that recompiling takes very little time, especially compared to running the test suites. So long as you don't modify any header files you shouldn't need to recompile everything anyway... iirc Walter's complaint is that the makefiles quickly get out of sync anyway, so it's a better habit to use make clean constantly regardless... "Trass3r" wrote in message news:op.v8l3w5s83ncmek@enigma... Is there any makefile guru who could (maybe use some fancy tool to) fix the dependencies? Having to recompile everything for each small change is annoying. Automate checking it and add that as one of the tests. I don't know about other people but something better than 80% (might even be north of 95%) of builds I run give errors (I tend to use compiler errors as a static analyses tool) and even when things build, I avoid running more than a few seconds worth of test until I think the codes correct. Run a clean build and test every so often (several times per hour) but MOST builds should be incremental so as to be as fast as can be managed.
Re: enum scope
On 01/25/2012 05:12 PM, Jonathan M Davis wrote: On Thursday, January 26, 2012 02:06:45 Trass3r wrote: When writing C bindings I usually create lots of aliases via a string mixin to pull enum members into the enclosing scope so it's compatible to C. Would it be wise to let the compiler do this automatically for extern(C) enums? Why? You're using them in D code, not C code. What difference does it make if the enum is one that's used in C code or not? Why would you use such aliases with enums from C but not those from D/ What makes enums from C different? - Jonathan M Davis Copy paste portability?
Re: Java memory efficiency and column-oriented data
On 02/02/2012 04:21 PM, bearophile wrote:
Through Reddit I've found this good and long slides pack, it's about using Java
data structures to increase memory efficiency of programs:
http://domino.research.ibm.com/comm/research_people.nsf/pages/sevitsky.pubs.html/$FILE/oopsla08%20memory-efficient%20java%20slides.pdf
Despite the D situation is different (there are structs as in C#), it will be
good to have weak and soft references in Phobos, and to have better memory
analysis tools outside Phobos.
The slides have reminded me my desire of a column-oriented "struct array" in
Phobos (some time ago someone has written a minimal version for D1).
The usage is simple:
import std.stdio, std.conv;
struct Foo { // an example struct
int x;
float y;
string s;
this(int xx, float yy) {
x = xx;
y = yy;
s = text(x);
}
float sum() {
return x + y;
}
}
void main() {
auto a1 = new Foo[1000]; // normal not parallel array
foreach (ref Foo f; a1)
writeln(f.s, " ", f.sum());
// default usage example of ParallelArray
// 3 Foo fields stored as 3 separated arrays inside a2
ParallelArray!Foo a2; // valid
static assert(a2[0].sizeof == size_t.sizeof * 4); // 3 pointers + 1 length
a2.length = 1000;
foreach (ref Foo f; a2) // A f Foo is built on the fly
writeln(f, " ", f.sum());
a2[10] = Foo(1, 2, "1");
foreach (x; a2.x_array) // x_array is a property slice
Ideally this shouldn't require the property. The "natural" or auto type
for iterating a ParallelArray should be a proxy value that defines
properties for all the members and looks them up on demand. It would
just need two words, a pointer to the parent ParallelArray and an index
into it.
writeln(x);
foreach (y; a2.y_array)
writeln(y);
foreach (s; a2.s_array)
writeln(s);
// specialized usage example of ParallelArray
// x,y fields stored as an array, s field as another array
ParallelArray!(Foo, "x y # s") a3; // valid
static assert(a3[0].sizeof == size_t.sizeof * 3); // 2 pointers + 1 length
a3.length = 1000;
foreach (ref Foo f; a3) // A f Foo is built on the fly
writeln(f, " ", f.sum());
a3[10] = Foo(1, 2, "1");
foreach (xy; a3.x_y_array)
writeln(xy.x, " ", xy.y);
foreach (s; a3.s_array)
writeln(s);
// float z0 = a3.x_y_array[10].sum(); // invalid code
ParallelArray!(Foo, "x # y # s") a4; // valid code
// ParallelArray!(Foo, "x y # s x") a5; // invalid, dupe field x
// ParallelArray!(Foo, "x # y") a6; // invalid, s field missing
// so if you give a string with the field names, you need to
// list them all, and only once each. Other designs are possible
// but this is the simplest to use and implement.
float z1 = a3[10].sum(); // a3[10] returns a Foo
// a3(10) doesn't create a Foo, it just fetches what
// .sum() needs, so it's faster if you have to call .sum()
// on many records.
// so the calls to sum() are implemented at compile-time
float z2 = a3(10).sum();
// To keep design simple. ParallelArray can't create 2D arrays
}
Do you like?
I have several usages of such struct in my code.
Bye,
bearophile
Re: [OT] I ported Empire to D2 and made it cross platform.
On 02/06/2012 03:00 AM, deadalnix wrote: Le 06/02/2012 05:16, Walter Bright a écrit : On 2/5/2012 6:44 PM, Bernard Helyer wrote: I've tried multiple times to contact Walter through his websites, but apparently _that's_ a dead end so... http://i.imgur.com/DzrN6.png Look at it! The selection pulses! Empire's never looked so good! There are some rough edges; the save games fail to load, demo isn't working, the text log isn't cleared correctly. But other than that you can happily play a game right through. I can't put the code anywhere because distribution is prohibited, so this is my last ditch effort to contact Walter. Here I am. Yes, it does look nice. Sorry, but please don't redistribute it. I don't see the point of it. It is advertisement for D. Some side effect of some long ago licensing agreement with a company that is now nothing more than a fileing cabinet full of paper and a lawyer on retainer?
Re: RedMonk rankings
On 02/09/2012 09:28 AM, Simen Kjærås wrote: http://redmonk.com/sogrady/2012/02/08/language-rankings-2-2012/ Kinda interesting, but as with all these things, don't take it as the word of god. Nice to see D all the way up there, I'd honestly expect it be lower. D is neck-n0neck with Go (:D) and behind LISP?!
Re: D-
On 02/10/2012 11:02 AM, Tim Krimm wrote: We have C and C++ How about D- and D? D- would be the have a similar use as today's C compilers. === Why create this language? === Well I would love to have a D compiler that supports microcontrollers. The ones that have say 32 K of RAM and 64K of FLASH. A language that is targeted for embedded and/or low resource environments. It would be nice to have a modern language for low resource environments. A potential way to implement this language is to use the DMD frontend, then flag the unsupported features of D, Next create a backend, like "C front" that outputs C code instead of assembler. === What do I envision with D-, D-- or Dm or what ever you want to call it. === This language would basically be D without the garbage collection. For example there would be structures but no classes. There would be regular arrays but no dynamic arrays. Code that is mostly equivalent to C, but you would still have structures with functions and overloading support, and other features like templates etc. I think you get the idea. What are your thoughts? If it's strict subset of D, then it could be done in a lint-esqu fashion by statical checking for anything not in the subset. I could see this as a patch to DMD that makes no modifications to the processing aside from adding extra errors. Any legal D- should be legal D and do exactly the same thing.
Re: D-
On 02/11/2012 12:58 AM, Paulo Pinto wrote: Am 10.02.2012 20:02, schrieb Tim Krimm: We have C and C++ How about D- and D? D- would be the have a similar use as today's C compilers. === Why create this language? === Well I would love to have a D compiler that supports microcontrollers. The ones that have say 32 K of RAM and 64K of FLASH. A language that is targeted for embedded and/or low resource environments. It would be nice to have a modern language for low resource environments. A potential way to implement this language is to use the DMD frontend, then flag the unsupported features of D, Next create a backend, like "C front" that outputs C code instead of assembler. === What do I envision with D-, D-- or Dm or what ever you want to call it. === This language would basically be D without the garbage collection. For example there would be structures but no classes. There would be regular arrays but no dynamic arrays. Code that is mostly equivalent to C, but you would still have structures with functions and overloading support, and other features like templates etc. I think you get the idea. What are your thoughts? I don't see the point. C++ was the last systems programming language without GC getting market share. I seriously doubt any new systems programming language without GC will ever suceed. Specially since systems programming in MacOS X and Windows world is Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work. slowly meaning the use of reference counting or GC in the vendor supported systems programming languages. Objective-C in MacOS X supports GC and Reference Counting (GC). C++ in Windows has the std::*ptr and handles in C++/CX. Then there is also C# for systems programming, when used in context of Microsoft Research projects like Singularity. So sum this up. If you need a languague without GC, C and C++ are quite good, have lots of tools and excellent compilers available. Do you need a very simple C like language, but with GC and a few improvements, Go might be an option. Do you need a language with GC, that is C++ done right and quite capable for systems programming, pick D. There is no need to D-. -- Paulo
Re: D-
On 02/11/2012 09:19 AM, Paulo Pinto wrote: Am 11.02.2012 18:00, schrieb bcs: On 02/11/2012 12:58 AM, Paulo Pinto wrote: Specially since systems programming in MacOS X and Windows world is Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work. Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course. OK then there may be some people doing systems programming for MacOS X and Windows, but they all work for Apple and MS. Regarding embedded and BIOS work, many systems being used today still required a custom C compiler without full ANSI C support, so how would such systems support a D- implementation? -- Paulo
Re: D-
On 02/12/2012 12:32 AM, Paulo Pinto wrote: Am 12.02.2012 03:03, schrieb bcs: On 02/11/2012 09:19 AM, Paulo Pinto wrote: Am 11.02.2012 18:00, schrieb bcs: On 02/11/2012 12:58 AM, Paulo Pinto wrote: Specially since systems programming in MacOS X and Windows world is Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work. Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course. OK then there may be some people doing systems programming for MacOS X and Windows, but they all work for Apple and MS. So do you mean everyone doing device driver development are also working for them? I've never worked on them but I seem to recall from somewhere that Windows drivers operate in an environment that has a lot of "supporting infrastructure". Assuming that's not off in the weeds, I suspect the cases is not to different for OS-x. As well as all the companies writing services/daemons with low level protocols for optimal perfomance? If you are working in user mode your claim to doing systems programming is weakened. The same goes if any part of your program can afford to use a GC. I will grant that there is a lot of ground between that and the "very much not systems programming" type of work that goes into a things like web apps. However, I would assert that a formal D- sub-set/dialect would mostly be of use on the core kernel development and embedded-systems/micro-controllers end of things. Outside that, I suspect that >90% of the advantage can be had via a well selected style guide.
Re: Why is there no or or and ?
On 02/16/2012 08:53 PM, bearophile wrote: Caligo: possible enhancement request? or is there a good reason it is not in the language? I have asked for them, but Walter doesn't want, he thinks C/C++ programmers will not use them... :-( Despite D != C/C++. Jonathan M Davis: And I'm actually mildly shocked that anyone (at least any programmer) would think that "or" and "and" were more readable. The fact that operators aren't words is a _major_ boon to code readibility. This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND". 'and' & 'or' are just a patch of meaningless squiggles with no more or less meaning than '&&' and '||' have. They have the meaning we impart to them. Personally, I associate '||' with the idea of disjunction just as much as I associate 'or'. Having the operators and the key-words/identifiers from different sets of characters, IMHO make things easer to read. "or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols, and they are much simpler told apart from bitwise& |. This avoids some bugs where people use "&&" where they want to use"&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them. Python got this way much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation. In a debate about readability, I don't give much weight to an argument that holds up Python as an ideal. Semanticly significant white-space? Are you kidding me?
Re: Why is there no or or and ?
On 02/16/2012 09:16 PM, Nick Sabalausky wrote: "Jonathan M Davis" wrote in message news:mailman.450.1329455016.20196.digitalmar...@puremagic.com... Seriously?&& and || are _way_ more readible, because they're obviously not functions or variables. It's immediately obvious what the operators are when scanning code. That's not the case when the operators are words instead of symbols. I'm certain that you'd have quite a few programmers up in arms if you tried to change&& to "and" and || to "or." And having multiple operators which do exactly the same thing is a horrible idea which reduces code readibility. So, even adding them as alternate options is a really bad idea IMHO. I'm surprised that anyone would think that and was better than&&. This is why I think people are nuts when they claim that english-like VB-style syntax is more readable than C-style. (Yea, to a grandmother with zero programming experience english-like languages are more readable. For a programmer it's worse becase code != english.) Any language that is designed to be easy for amateurs to use will be used by amateurs, and only by amateurs. Yes, avoid making the language unnecessarily hard for beginners, but don't in any way compromises the language to do so.
Re: Remote unix text editing (Was: Why is there no or or and ?)
On 02/18/2012 09:10 AM, Nick Sabalausky wrote: "James Miller" wrote in message news:mailman.523.1329551034.20196.digitalmar...@puremagic.com... I would like to add a few more points. I exclusively use (g)vim text editing, why? Because it means I can jump on a console, SSH into a server, and it will probably have vim, or atleast vi. I've heard a lot of people say that about vi(m), but in my (admittedly somewhat limited) experience, I've never come across a (Li|U)n[ui]x system that didn't have nano or pico (neither of which are great, but they're good enough for editing Unix configuration files, and I'm actually capable of using them, unlike emacs or vim). Vi's not that hard to use if you don't expect to be a power user. But I prefer to do it like this: SSH into a server, but then also connect via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I can use *any* editor I want: kate, gedit, whatever. How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases (I need to edit one line of one config file on this server I touch less than once a quarter. If I'm using a server that doesn't already have ssh set up (for instance, if I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can, I'll install mcedit which is the closest I've seen to what I would consider a nice text-mode editor.
Re: Why is there no or or and ?
On 02/16/2012 09:14 PM, H. S. Teoh wrote: On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote: On 2/16/2012 8:47 PM, H. S. Teoh wrote: Well, in that case, we should replace 'in' with '∈'. I would, but that doesn't work because of keyboarding issues. I wasn't being serious. I was going to suggest to those who complain about&& being too similar to&, that we should adopt ∧ and ∨ instead. Nice and readable, and unambiguous. And we could use ∀ instead of 'foreach'; that would save so much typing! ∀ is "for all" so it couldn't be used. The code might hit a break. I mean, D is already standardized on Unicode, why not take advantage of all those nice symbols that Unicode provides? ;-) (As long as you don't mention APL, everybody will be just fine.) T
Re: Why is there no or or and ?
On 02/18/2012 11:21 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 09:45:10AM -0800, bcs wrote:
On 02/16/2012 09:14 PM, H. S. Teoh wrote:
On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote:
On 2/16/2012 8:47 PM, H. S. Teoh wrote:
Well, in that case, we should replace 'in' with '∈'.
I would, but that doesn't work because of keyboarding issues.
I wasn't being serious. I was going to suggest to those who complain
about&& being too similar to&, that we should adopt ∧ and ∨ instead.
Nice and readable, and unambiguous. And we could use ∀ instead of
'foreach'; that would save so much typing!
∀ is "for all" so it couldn't be used. The code might hit a break.
[...]
We could replace 'if (cond) break;' to 'except (cond)', so it would be
"for all ... except". So you'd have:
int[] array = [ ... ];
∀ x ∈ array except (x==42) {
...
}
That would work for continue, but not break. ∀ and ∈ are set operators
and foreach is inherently a sequence operation.
OTOH a "∀ ... ∈ ... → ..." statement that does have set semantics
(un-ordered, independent evaluations) would be interesting. It would be
parallelizable for one things. The trick would be figuring out how to
combine side effects and prevent race conditions. Has any language
formalised the concept of transitive side effects?
Re: Why is there no or or and ?
On 02/19/2012 07:25 AM, Kevin Cox wrote: Vb yes, python kinda. Vb is designed for people who don't want to program. The idea is to create a quick application that gets two job done. Python is slightly different. It has a ton of syntax and all the libraries that it needs to be used in moderately sized project. Python comes across as being easy to learn because it is simple in the most beautiful way. I doubt many large programs are written in python but of course it is finding a home on the web. I think that python stretches close to the line but I doubt it was designed for beginners. What he said. On Feb 19, 2012 10:20 AM, "Stewart Gordon" mailto:smjg_1...@yahoo.com>> wrote: On 17/02/2012 06:09, bcs wrote: Any language that is designed to be easy for amateurs to use will be used by amateurs, and only by amateurs. Do you consider either VB or Python to fall under that category? Stewart.
Re: Remote unix text editing (Was: Why is there no or or and ?)
On 02/18/2012 06:13 PM, Nick Sabalausky wrote: "bcs" wrote in message news:jhonpv$neg$1...@digitalmars.com... On 02/18/2012 09:10 AM, Nick Sabalausky wrote: I've heard a lot of people say that about vi(m), but in my (admittedly somewhat limited) experience, I've never come across a (Li|U)n[ui]x system that didn't have nano or pico (neither of which are great, but they're good enough for editing Unix configuration files, and I'm actually capable of using them, unlike emacs or vim). Vi's not that hard to use if you don't expect to be a power user. I figure I could probably get by with it (if I had to) as long as I grabbed a command reference and kept it nearby. But so far, I haven't felt any need or desire to do so. I'm in a similar position, vi is my tty console editor of choice but not my goto editor for anything of much significance. But I prefer to do it like this: SSH into a server, but then also connect via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I can use *any* editor I want: kate, gedit, whatever. How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases Same speed as any normal SSH login. Only difference is instead of doing: $ssh user@domain You do: $sshfs user@domain: /desired/local/mount/point Or if you don't want it rooted on the remote user's home dir: $sshfs user@domain:/ /desired/local/mount/point # the whole damn remote system or $sshfs user@domain:/remote/dir /desired/local/mount/point Then to logout, it's just: $fusermount -u /desired/local/mount/point It literally is SSH, so the actual login process is exactly the same as SSH, whether you use a key-pair or a full login/pass. So however fast that is, that's how fast SSHFS is. I've never noticed any difference. That's kind of borderline for some uses.
