DQuick news
Latest news of DQuick for this year. The good news is, the project still alive and Bruno added some interesting stuff to the DMLengine : - Adding support of arrays - Adding support of delegates - Improve error reporting from Lua Our minesweeper sample works well but don't use arrays for the moment. About arrays, a signal is emitted for the entire array, not for each values. It completely different to the Qt choice use QAbstractListModel, this force the user to create a wrapper for properties on array or list. Our solution works without any wrapper, but we have to do some real tests to see if it's a valid solution. I hope 2014 will be the year when DQuick could be tested/used by some of you, but for that we need add some missing features, fix a lot of bugs and firstly works on the documentation (that is completely inexistent).
Re: DQuick news
On Sunday, 29 December 2013 at 01:15:50 UTC, Xavier Bigand wrote: - Improve error reporting from Lua I looked at the commit log. I like how you are *already* fixing Lua bugs... still not considering LuaD? :P
Re: DQuick news
On Sunday, 29 December 2013 at 01:15:50 UTC, Xavier Bigand wrote: Latest news of DQuick for this year. The good news is, the project still alive and Bruno added some interesting stuff to the DMLengine : - Adding support of arrays - Adding support of delegates - Improve error reporting from Lua Our minesweeper sample works well but don't use arrays for the moment. About arrays, a signal is emitted for the entire array, not for each values. It completely different to the Qt choice use QAbstractListModel, this force the user to create a wrapper for properties on array or list. Our solution works without any wrapper, but we have to do some real tests to see if it's a valid solution. I hope 2014 will be the year when DQuick could be tested/used by some of you, but for that we need add some missing features, fix a lot of bugs and firstly works on the documentation (that is completely inexistent). Does dQuick ready for writing very simple apps with several buttons and other simple controls?
Re: Mobile App STACK4 with a D backend
On 28.12.2013 19:22, Stephan Dilly wrote: Well yeah that was alreday clear... i meant the answer someone posted there: Just go to settings-apps and transfer the game from internal onto your phone memory. It's a common issue Does this solve the problem ? Sorry, missed that. Yes that solves the problem. -- mk
Re: DQuick news
Le 29/12/2013 09:26, Jakob Ovrum a écrit : On Sunday, 29 December 2013 at 01:15:50 UTC, Xavier Bigand wrote: - Improve error reporting from Lua I looked at the commit log. I like how you are *already* fixing Lua bugs... still not considering LuaD? :P We don't fix Lua, it was about how the DMLEngine catch Lua's errors and forward it to the D part, there was also some issues when there is mismatch between D signature and Lua calls,... Bruno took a look to LuaD, but for the moment he is more comfortable with Lua and he really need to be on latest Lua version. I forgot to tell we add the dub support to build the project.
Re: Delight
On Thursday, 25 September 2008 at 14:27:42 UTC, bearophile wrote: Mosfet: Is there any performance loss from compared to D language ? No, it's just D1 resyntaxed. That is, it generally improves on the old-school syntax of D ;-) Bye, bearophile Improves is pretty subjective...
Re: Range-Based Graph Search in D (blog post)
On Saturday, 11 January 2014 at 03:53:28 UTC, Timon Gehr wrote: One issue with the API is that it does not deal with graphs with more than one edge between two given vertices very well. I think it'd need a separate edge abstraction. (Formally, a graph is just a pair of sets (V,E) with two functions from E to V giving you start and end vertex of an edge.) I was thinking of changing the adjacency list to return a range of edges instead. That may solve the problem. It also solves the problem of the edgeWeight API being inefficient for certain graph data structures. A graph search can have more properties than just the sequence of visited edges, so maybe it is not a range, but just provides a range. (And maybe also a range of events, usable instead of callbacks, maybe a DFS tree etc.) A range of events would be interesting. You could then get a range of different events by filtering: graph.depthFirstSearchEvents(start).filter!(e = e.type == Event.node).map!(e = e.node); etc. Allocation of memory for visited flags and the like should be controllable. Maybe the design should even allow using persistent data structures for storing visited flags, such that the search range can be used as a value type / forward range. Absolutely. I'm leaving things like memory allocation API until later and focussing on the general usability and flexibility. Probably it would be worthwhile to explore a design that is similar to Phobos ranges at some level. I.e. support kinds of graphs with different capabilities. (Eg. your implicitGraph cannot enumerate all vertices or edges that are present in the Graph. The least capable graph kind reasonably supported might not even be able to quickly report all adjacent edges to a vertex. Some graphs may allow in-place mutation etc.) Then provide some explicit representations with high capabilities and helper functions to convert certain representations to (more) explicit representations. (similar to constructing eg. an array from a range.) Constructions on graphs would then return implicit representations. Yah, I only implemented implicit graph first due to it's simple representation. It's mainly useful for infinite graphs like game trees and works well for some other simple graph types, but certainly there will be a need for other types of graph (adjacency matrices, edge lists, adjacency lists, etc.) It's also a very minimal graph type, which is useful for testing a generic API. I want the algorithms to require only as much as necessary from the graph representation. If users have to construct large graph data type with many mandatory member functions then I would be unhappy. Thanks for all the feedback.
Re: Coming back, Unique, opDot and whatever else
On 2014-01-17 21:25, Stanislav Blinov wrote: Ahem. Wasn't it what I said? :) I don't know, perhaps I missed that :) Of course I did try. My concern is that it would stop accepting arbitrary user types. Most times this would be a good thing. But not always. Hence I'm hesitating :) Right, but the opposite could be said as well. If it's not marked with @safe no other functions marked with @safe can call the function. But any non-safe function can call @safe functions. Oh, I didn't say so, but of course once they're out of class, they're bound to have proper names. I don't know if you've caught that comment in the code, but I basically intentionally named them ugly to minimize collisions. I didn't think of that. Perhaps using two underscores instead then, since the compiler is has reserved those names no one else should use them. I think this is an edge case where this could be allowed. Alternatively, as you wrote in a comment, use free functions. Since they would be declared in the same module they would have access to the private data. Hmm, but the compiler prefers opDispatch before UFCS. Heh, now I'm even more leaning towards a proxy. Because honestly, x.opDispatch!(release)() is even uglier than x.opDot().release() :D By proxy I mean replacing opDot() with a mixin that would directly inject a Unique with an interface of a wrapped object. That has some problems (like how to forward calls to template functions), but hey, I'm experimenting here! Does opDot even work? -- /Jacob Carlborg
Re: Range-Based Graph Search in D (blog post)
On Saturday, 11 January 2014 at 09:11:45 UTC, Philippe Sigaud wrote: * I sometimes have to use graphs with more than just `weight` on edges (names as strings, chars, for example for a state machine, etc). Do you think you could extend your design to allow parameterization on edges? Of course, to use the search algorithms, the user should provide an way to get a priority from the edges. Or any user-defined type could be used, ideally, as long as it provides a way to get a `size_t`. Yes, I think this should be possible. I think I will allow arbitrary edge types so the user can attach whatever information they like, and then these can be retrieved through an edge event visitation of the graph. * I'd like a way to map on a graph (keeping the edge structure, but changing the nodes contents). I know I can map on your search result, but 1) I want a graph after mapping, not a range and 2) I don't want to search, I want to affect all nodes. Interesting. I think that should be possible if you provide some sort of adaptor on the graph that modifies the result of the adjacent function. * I'd like a way to iterate seeing only edges, not nodes. Yes, I think I will change the search range to be a range of events, which will include edges taken and vertices visited among other things. You can then filter the events to only see edge events if you wish. * I'd like a way to concatenate/link different graphs (a bit like chain for ranges). I sometimes have graphs that are assembled from many different small graphs, bottom-up style. Typically, if you assemble automata (from regexes, for example), you do it bottom-up. Should be possible, but I think that would be up to the user to do the combination. They just need to provide the correct API. * Of course, I'd like a way to build a graph from nothing, putting nodes and then edges in them. Yep, I'll add some real graph data structures later :-) I understand implicit graphs aren't everything! * I sometimes need to extract some global information from a graph: number of nodes, number of edges, etc. Any graph that can provide that would be free to do so. * Does you design allow for backward iteration? (I mean, inverting the edges). Some graph algorithms ask for this kind of magic. True. Implicit graph would struggle to provide that, but other graphs would be able to provide incidentEdges as part of the API (easy for adjacency matrix for example). * Getting strongly connected components is a very interesting algorithm to have. Absolutely, I'll likely move onto connected components and graph flow next. * you should define some template constraints on your types (Graph...), but I understand they can be added later on. Yeah, it's not very robust at the moment, just experimental :-) I find adding constraints early just gets in the way of experimentation. Re-reading my suggestions, I see they would push your code toward my own attempts :-) I guess I'm biased. I have some (years old!) code in there: https://github.com/PhilippeSigaud/dranges/blob/master/graphrange.d https://github.com/PhilippeSigaud/dranges/blob/master/graph.d https://github.com/PhilippeSigaud/dranges/blob/master/graphalgorithm.d As for my (age old) vision on graph iteration, here it is: https://github.com/PhilippeSigaud/dranges/blob/master/recursive.d But yet again, nothing as elegant as your own code. Thank you for the feedback. I will have a look at your code for inspiration!
Re: Coming back, Unique, opDot and whatever else
On Friday, 17 January 2014 at 20:25:37 UTC, Stanislav Blinov
wrote:
Heh, now I'm even more leaning towards a proxy. Because
honestly, x.opDispatch!(release)() is even uglier than
x.opDot().release() :D...
Well, what can I say? I didn't need to go very far. Because
Phobos has such proxy. Which is called std.typecons.Proxy :) I
skimmed over it in the docs several times, probably because the
docs just say Make proxy for a. without going into much detail.
But the last time I spotted it, associative memory kicked in, I
guess, and I stayed a bit longer to actually look at the example.
There is, however, at least one issue with it: template arguments
are not forwarded properly:
---
class Widget {
auto inconsistent(T...)(T args) if (T.length) { return args[0];
}
}
auto widget = new Widget;
widget.inconsistent(hello, 10, 20); // works
auto uwidget = createUnique!Widget();
uwidget.inconsistent(hello, 10, 20); // Error: template
instance inconsistent!() does not match template declaration
inconsistent(T...)(T args) if (T.length)
uwidget.inconsistent!(string,int,int)(hello, 10, 20); //works
---
I hadn't had a chance for a closer inspection yet as to why
though. In any case, that Proxy is a nice thing to have in the
library!
Re: dmd 2.065 beta 1
Andrew Edwards wrote in message news:lbdumk$2oki$1...@digitalmars.com... [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip Windows bin folder is empty. I'd post on the list but I'm not sure it's working at the moment.
Re: dmd 2.065 beta 1
On 1/18/14, 8:42 AM, Daniel Murphy wrote: Andrew Edwards wrote in message news:lbdumk$2oki$1...@digitalmars.com... [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip Windows bin folder is empty. I'd post on the list but I'm not sure it's working at the moment. Thanks. New file uploaded.
Re: dmd 2.065 beta 1
Am 18.01.2014 15:13, schrieb Andrew Edwards: On 1/18/14, 8:42 AM, Daniel Murphy wrote: Andrew Edwards wrote in message news:lbdumk$2oki$1...@digitalmars.com... [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip Windows bin folder is empty. I'd post on the list but I'm not sure it's working at the moment. Thanks. New file uploaded. still not fully automated build down to zip file :)
Re: dmd 2.065 beta 1
Andrew Edwards wrote in message news:lbe25n$2rrh$1...@digitalmars.com... Thanks. New file uploaded. Looking much better. I extracted this beta and the last release, and diffed the result of `dir /s` to see what changed. Some of these may be intentional, thanks to problems with the old zip - There are .DS_Store file scattered around now, these should be removed - This does not have the right version of optlink - has 8.00.13 should be 8.00.15 (check it's 223,260 bytes) - dmd2\windows\lib64 is gone... - gained phobos\std\typelist.d - lost a bunch of files in dmd2\src\druntime\src\gc - XXX\dmd2\src\VERSION now has a windows line-end... not sure if this is a problem or not - libcurl_stub.c appeared in XXX\dmd2\linux\lib* - XXX\dmd2\html\d\phobos\phobos.html disappeared
dmd 2.065 beta 1
Beta testing for dmd 2.065 is under way. You can access the associated zip at [1] and view the current list of regressions at [2]. Make every effort to provide a thorough review so we can get the best product out the door. Please refrain from discussing the review here in the dlang.org forums. Instead, post all concerns to the dmd-beta mailing list at [3]. If you haven't already done so, you will need to register to the mailing list at [4]. When submitting bug reports associated with this review, ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger. [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip [2] http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED [3] http://forum.dlang.org/group/dmd-beta [4] http://lists.puremagic.com/mailman/listinfo/dmd-beta
Re: dmd 2.065 beta 1
On 1/18/2014 7:33 AM, Daniel Murphy wrote: Andrew Edwards wrote in message news:lbe25n$2rrh$1...@digitalmars.com... Thanks. New file uploaded. Looking much better. I extracted this beta and the last release, and diffed the result of `dir /s` to see what changed. Some of these may be intentional, thanks to problems with the old zip - There are .DS_Store file scattered around now, these should be removed - This does not have the right version of optlink - has 8.00.13 should be 8.00.15 (check it's 223,260 bytes) - dmd2\windows\lib64 is gone... - gained phobos\std\typelist.d - lost a bunch of files in dmd2\src\druntime\src\gc - XXX\dmd2\src\VERSION now has a windows line-end... not sure if this is a problem or not It's a problem. There cannot be line endings in it. - libcurl_stub.c appeared in XXX\dmd2\linux\lib* - XXX\dmd2\html\d\phobos\phobos.html disappeared
Re: dmd 2.065 beta 1
On 1/18/2014 6:24 PM, Daniel Murphy wrote: Walter Bright wrote in message news:lbelqh$e54$1...@digitalmars.com... It's a problem. There cannot be line endings in it. The one in the git repo has a unix line ending. Must have been the dang git software!
Re: Coming back, Unique, opDot and whatever else
On Sunday, 19 January 2014 at 22:25:08 UTC, Rory McGuire wrote: opDispatch works do you can just type object.release This will call Unique's release(). To get to wrapped object's release(), you need object.opDispatch(release)().
Re: dmd 2.065 beta 1
On Saturday, 18 January 2014 at 13:13:56 UTC, Andrew Edwards wrote: Beta testing for dmd 2.065 is under way. You can access the associated zip at [1] and view the current list of regressions at [2]. Make every effort to provide a thorough review so we can get the best product out the door. Please refrain from discussing the review here in the dlang.org forums. Instead, post all concerns to the dmd-beta mailing list at [3]. If you haven't already done so, you will need to register to the mailing list at [4]. When submitting bug reports associated with this review, ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger. [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip [2] http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED [3] http://forum.dlang.org/group/dmd-beta [4] http://lists.puremagic.com/mailman/listinfo/dmd-beta Can we have the deb, rpm and whatnot ?
Re: forum.dlang.org moved to a new server
On Wednesday, 25 December 2013 at 15:34:06 UTC, Somedude wrote: http://www.filedropper.com/xhrerrorpcapng Thanks, I believe the problem should be fixed now.
Re: Microsoft working on new systems language
On Sat, 28 Dec 2013 03:13:53 -0800, Barry L. barry.lapth...@gmail.com wrote: Hello everyone, first post... Just saw this: http://joeduffyblog.com/2013/12/27/csharp-for-systems-programming/ D (and Rust) get a mention with this quote: There are other candidates early in their lives, too, most notably Rust and D. But hey, my team works at Microsoft, where there is ample C# talent and community just an arm’s length away. I want to make a point here that many people come to do looking for something that is as performant as C++ with the ease of C# or Java, and for the most part (using LDC/GDC) you get exactly that. This language could convince me to go back to C#. Particularly if it's cross-platform. C# is a solid language that is used by a lot of people. And it is supported by a large corporate entity with mountains of money and a vested interest in making it successful. They can kill bugs and make improvements at a phenomenal pace (look at the job they did with C# 1.0-2.0). This needs to be a wake up call for the D community. For a long time D has occupied the Programmer Efficient and Safe Native Compiled Language niche more or less unchallenged in any serious way (with a nod to Rust). If Microsoft actually goes through with this (and they will since the .NET runtime is murderous on mobile device battery performance) the argument for D will get much harder to make. Yes we can argue the ideology of one technical bullet point versus another, but that misses the point. The vast majority of programmers pick their languages based not on ideological purity, but on ability to get stuff done quickly. Obviously this is more than just the language, it's also the availability of tutorials and examples. But there isn't much we can do about that at this point. And there is a LOT of things that C# can do that D cannot. Cross-library namespace composability is big on my personal list. Or proper shared libraries. Or, etc. I know that I wanted out of the Microsoft world for performance and cross-platform reasons. However with this project, especially the interest in cross-platforming it that they seem to be showing, they will have a much easier time getting me back. After all I came from to D from C#, it wouldn't be hard to go back. So while we're celebrating that D mentioned in an article that made the front-page of reddit (by virtue of it's author being well-respected and the importance of his employer) let us also reflect on what this news most likely means for D. Microsoft can invalidate us almost overnight with mountains money and the size of their community. Yes we got an honorable mention, that also means we're on the radars of people who matter... -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: DIP54 : revamp of Phobos tuple types
Winter holidays have distracted me a bit, back to this topic. I have been thinking about concerns mentioned for a while, this is proposed update to DIP in question to address those. Hope that will be a more acceptable compromise to everyone. 1) Timon has raised the point that exact match between in naming between built-in and library type will be confusing as they will actually differ in behavior (http://forum.dlang.org/post/l99mke$q1o$1...@digitalmars.com). Andrei has proposed `TemplateArgumentPack` as an alternative (http://forum.dlang.org/post/l9b5cu$2rsj$2...@digitalmars.com) which I do like a lot. That will also imply naming of module `std.meta.pack` instead of `std.meta.list` 2) Despite my initial desire to standardize API between library types it seems that breakage will be much more damaging than I have initially expected. Jakob example (http://forum.dlang.org/post/vkeqyorptcobufzmm...@forum.dlang.org) does not look _that_ bad but imagining is(typeof()) error suppression on top is pain. I reconsider that proposal. As an alternative, I propose signatures of existing templates as-is but augment them all with overloads taking single `Pack` (and make it requirement when introducing new ones). New multilist utilities added are expected to use `Pack`s (I am still convinced that using nested templates for that is ugly) 3) Point about omitting expanding library type still remains. I am still looking for use case when those are really necessary (as a library type). Does that look more acceptable? Jakob, Andrej?
groupBy predicates: unary, binary, or both?
I'm working on https://github.com/D-Programming-Language/phobos/pull/1186, which is somewhat important; group by is a powerful operation. Along the way, I stumbled upon an interesting issue in which I wanted to consult the community. Usually groupBy is used to find runs of equivalent elements in a range. For example: [1, 1, 1, 2, 2, 3, 3, 3, 4, 5, 5, 6].groupBy() yields the range [[1, 1, 1], [2, 2], [3, 3, 3], [4], [5, 5], [6]]. As is usual with Phobos algorithms, groupBy accepts a predicate. The default (as illustrated above) is a = b, i.e. all elements in a group are equal to one another. Equality is transitive and commutative. But there are useful cases in which predicates are not commutative. Consider we want to find strictly monotonic subranges in the range. We'd write: auto r = [1, 3, 2, 4, 5, 1].groupBy!a b; That should produce [[1, 3], [2, 4, 5], [1]]. For non-strict monotonic runs, the predicate would be a = b etc. All that is pretty awesome. However, that makes life a bit tougher for the algorithm - it must only compare adjacent elements only. In the case of a = b, it suffices to save the first element in a group and compare it against every other element in the group. Meanwhile, a very similar pull request (https://github.com/D-Programming-Language/phobos/pull/1453) uses unary predicates, i.e. an optional transformation function that is then used in conjunction with == to decide which elements belong in the same group. Unary predicates make life simpler for the algorithm (save the transform of the first element, then compare it against the transform of the next etc) and are often easier to write by the end user, too (e.g. just write a.length instead of a.length == b.length to group by length). So I was thinking to allow both cases, with the understanding that grouping by unary predicates uses == for comparison whereas grouping by binary predicates looks at adjacent elements to figure out group membership. That approach would, however, preclude the use of string lambdas (because deducing arity for string lambdas is possible, but quite unwieldy). What do you think? Andrei
Re: Microsoft working on new systems language
On 29.12.2013 06:59, Adam Wilson wrote: On Sat, 28 Dec 2013 03:13:53 -0800, Barry L. barry.lapth...@gmail.com wrote: Hello everyone, first post... Just saw this: http://joeduffyblog.com/2013/12/27/csharp-for-systems-programming/ D (and Rust) get a mention with this quote: There are other candidates early in their lives, too, most notably Rust and D. But hey, my team works at Microsoft, where there is ample C# talent and community just an arm’s length away. I want to make a point here that many people come to do looking for something that is as performant as C++ with the ease of C# or Java, and for the most part (using LDC/GDC) you get exactly that. This language could convince me to go back to C#. Particularly if it's cross-platform. C# is a solid language that is used by a lot of people. And it is supported by a large corporate entity with mountains of money and a vested interest in making it successful. They can kill bugs and make improvements at a phenomenal pace (look at the job they did with C# 1.0-2.0). This needs to be a wake up call for the D community. For a long time D has occupied the Programmer Efficient and Safe Native Compiled Language niche more or less unchallenged in any serious way (with a nod to Rust). If Microsoft actually goes through with this (and they will since the .NET runtime is murderous on mobile device battery performance) the argument for D will get much harder to make. Yes we can argue the ideology of one technical bullet point versus another, but that misses the point. The vast majority of programmers pick their languages based not on ideological purity, but on ability to get stuff done quickly. Obviously this is more than just the language, it's also the availability of tutorials and examples. But there isn't much we can do about that at this point. And there is a LOT of things that C# can do that D cannot. Cross-library namespace composability is big on my personal list. Or proper shared libraries. Or, etc. I know that I wanted out of the Microsoft world for performance and cross-platform reasons. However with this project, especially the interest in cross-platforming it that they seem to be showing, they will have a much easier time getting me back. After all I came from to D from C#, it wouldn't be hard to go back. So while we're celebrating that D mentioned in an article that made the front-page of reddit (by virtue of it's author being well-respected and the importance of his employer) let us also reflect on what this news most likely means for D. Microsoft can invalidate us almost overnight with mountains money and the size of their community. Yes we got an honorable mention, that also means we're on the radars of people who matter... Well, this is nothing new I would say. Microsoft Research already has been using C# for systems programming in the context of the Singularity project (Sing#). They just didn't brought the result of their work into mainstream Windows, except for the MDIL compiler used in WP8. Now with the native political side gaining strength after the Vista fiasco, it is to be expected something like this, if the wind doesn't change again. A future native C# compiler was also mentioned at VS 2013 release keynote. -- Paulo
Re: Microsoft working on new systems language
On 2013-12-29 06:59, Adam Wilson wrote: The vast majority of programmers pick their languages based not on ideological purity, but on ability to get stuff done quickly. I get the feeling most developers pick the default language of the platform they develop for. On Windows that means .Net and most likely C#, on Mac OS X it means Objective-C. I guess that it also means those are the languages which makes it easy do get stuff done quickly for those platforms because that's where the companies invest their money. -- /Jacob Carlborg
Re: What is the rationale behind std.file.setAttributes ?
On Sunday, 29 December 2013 at 11:01:05 UTC, Marco Leise wrote: Basic OS level file-system I/O support is useful on its own, especially in a systems programming language. You don't need to pull in a whole bunch of dependencies to read a text file. Yes, it is useful to have good bindings for OS-level apis. However, Posix is no longer an adequate abstraction for cross-platform file systems. In the cloud or in clusters you mount network drives with other properties than a local drive. It is much better to encourage a high-level interface for general file access. That encourage a more portable design for an application. That makes porting much easier. Porting software that assumes a local drive to the cloud is tedious. You don't pull in whole bunch of dependencies. You include the modules you need and they share the same interface. That's a clean design. The file module reminds me of Perl and old Php, that was ok in the 1990s, but it is the wrong way of creating a file system abstraction in 2014. If you just want to read and write a file with a specific path there is no reason for using a non-portable interface. Encourage a portable interface and porting to the cloud becomes trivial: you just swap out the context-object.
Re: groupBy predicates: unary, binary, or both?
There is precedence for this in phobos with schwatzSort: It use a unaryFun, followed by a binaryFun. I've found this works quite well: More often than not, a unary fun is more than enough (the default a b/a == b is fine). And in the cases where you *do* need binary comparison, then having a unary fun anywas is fine. EG: MHklfsJKGsfd.byGroup!(std.uni.tolower, a b)(); I think it is both an elegant and efficient approach. That's what I'd go for. --- I think we should handle non-commutative predicates. It's not actually *that* much more complicated. Instead of storing in each Group a value + range, simply save the range twice, and have one range be 1 step ahead of the first. I think a few phobos algos do this. minPos does something kind of similar. The overhead is an initial extra save yes, but the cost of each pop is to simply pop both ranges (no extra saves there). You never actually have to make element copies (which may fail if the range holds const elements to boot...). Also, if the ElementType is big, then storing an extra range has good chances to actually take up *less* room. My stance is that supporting this would be a powerful and useful tool, and I don't think there'd be that much overhead either, so I say let's go for it.
Re: Microsoft working on new systems language
On Sunday, 29 December 2013 at 13:15:14 UTC, Ola Fosheim Grøstad wrote: I think neither Go, D or this language is as performant as (skilled use of) C/C++. This is not true. Assuming skilled use and same compiler backend those are equally performant. D lacks some low-level control C has (which is important for embedded) but it is not directly related to performance.
Re: groupBy predicates: unary, binary, or both?
Andrei Alexandrescu: which is somewhat important; group by is a powerful operation. I agree, it's a quite commonly useful operation. So I was thinking to allow both cases, with the understanding that grouping by unary predicates uses == for comparison whereas grouping by binary predicates looks at adjacent elements to figure out group membership. That approach would, however, preclude the use of string lambdas (because deducing arity for string lambdas is possible, but quite unwieldy). In similar cases the simplest solution is to have two functions with different (but similar) names. However, that makes life a bit tougher for the algorithm - it must only compare adjacent elements only. But another common need is to group by equivalent classes using an associative array. Both C# and Clojure have this functionality (on LINQ and in the functions toolkit). This means that a hashGroup builds an associative array inside and returns it. See also: http://d.puremagic.com/issues/show_bug.cgi?id=5968 http://d.puremagic.com/issues/show_bug.cgi?id=9842 Bye, bearophile
bugtracker and auto-tester down
I can't access http://d.puremagic.com/issues/ for at least an hour now. On a related note, http://d.puremagic.com/test-results/ seems to be down, too.
Re: What is the rationale behind std.file.setAttributes ?
On Saturday, 28 December 2013 at 08:18:44 UTC, Jonathan M Davis wrote: on it specifically. My main point was that some stuff in std.file is system- specific and that if it has to be, it's better to have it in std.file as system- specific rather than not having it at all just because it couldn't be completely cross-platform and portable. So, just because setFileAttributes is doing something system-specific does not mean that it's bad. Agreed. And really I didn't want to make a point about how it should be done right when I started this thread. This particular function just seemed not in line with Phobos principles as I remember them. :) Am Sat, 28 Dec 2013 09:02:01 + schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com: It is bad. If you want system-specific behaviour you should have a separate interface that provide all the advantages that going to a lower level provides. Having half-assed OS-specific support is too pragmatic and will lead to a legacy mess in the long run when those interfaces become obsolete. A good file abstraction should also support newer file systems like Google Cloud Storage, though. GCS does not support append() or directories. A good file abstraction should also provide mechanisms to deal with different levels of consistency on the underlying filesystem and caching-mechanism: - read after write might return an old version - read after write returns the new version if read from the same computer - read after write always returns the new version As a new language D should support Cloud based environments out-of-the-box with a hierarchy of functionality down to the peculiarities of Windows/Posix etc so that you can decide to code in a manner that supports all platforms without having to litter your code with ifs and version-statements… and also restrict you to the subset you have authorized so that you can develop on your Windows system and port it to the cloud with just a recompile without knowing the details of the cloud file system. (i.e. the compiler warns you when you are using system specific functionality). I also think good file system support implies built-in caching and let the library decide whether to turn library-level caching on or off based on what the operating system or underlying interface supports. E.g. the ability to tell the system that you want successive reads of a file to be available fast at the cost of consistency. Are you hijacking this thread to ask for Google Cloud support? ;) Don't forget FTP, SSH, WebDAV, ... Implementing all of this can take quite some time and will result in something like the Gnome virtual file-system. It might become so large that std.file is easily reimplemented as a tiny part of it for the native file-system module. Basic OS level file-system I/O support is useful on its own, especially in a systems programming language. You don't need to pull in a whole bunch of dependencies to read a text file. -- Marco
Re: Microsoft working on new systems language
On Sun, 29 Dec 2013 00:45:39 -0800, Paulo Pinto pj...@progtools.org wrote: On 29.12.2013 06:59, Adam Wilson wrote: On Sat, 28 Dec 2013 03:13:53 -0800, Barry L. barry.lapth...@gmail.com wrote: Hello everyone, first post... Just saw this: http://joeduffyblog.com/2013/12/27/csharp-for-systems-programming/ D (and Rust) get a mention with this quote: There are other candidates early in their lives, too, most notably Rust and D. But hey, my team works at Microsoft, where there is ample C# talent and community just an arm’s length away. I want to make a point here that many people come to do looking for something that is as performant as C++ with the ease of C# or Java, and for the most part (using LDC/GDC) you get exactly that. This language could convince me to go back to C#. Particularly if it's cross-platform. C# is a solid language that is used by a lot of people. And it is supported by a large corporate entity with mountains of money and a vested interest in making it successful. They can kill bugs and make improvements at a phenomenal pace (look at the job they did with C# 1.0-2.0). This needs to be a wake up call for the D community. For a long time D has occupied the Programmer Efficient and Safe Native Compiled Language niche more or less unchallenged in any serious way (with a nod to Rust). If Microsoft actually goes through with this (and they will since the .NET runtime is murderous on mobile device battery performance) the argument for D will get much harder to make. Yes we can argue the ideology of one technical bullet point versus another, but that misses the point. The vast majority of programmers pick their languages based not on ideological purity, but on ability to get stuff done quickly. Obviously this is more than just the language, it's also the availability of tutorials and examples. But there isn't much we can do about that at this point. And there is a LOT of things that C# can do that D cannot. Cross-library namespace composability is big on my personal list. Or proper shared libraries. Or, etc. I know that I wanted out of the Microsoft world for performance and cross-platform reasons. However with this project, especially the interest in cross-platforming it that they seem to be showing, they will have a much easier time getting me back. After all I came from to D from C#, it wouldn't be hard to go back. So while we're celebrating that D mentioned in an article that made the front-page of reddit (by virtue of it's author being well-respected and the importance of his employer) let us also reflect on what this news most likely means for D. Microsoft can invalidate us almost overnight with mountains money and the size of their community. Yes we got an honorable mention, that also means we're on the radars of people who matter... Well, this is nothing new I would say. Microsoft Research already has been using C# for systems programming in the context of the Singularity project (Sing#). They just didn't brought the result of their work into mainstream Windows, except for the MDIL compiler used in WP8. Now with the native political side gaining strength after the Vista fiasco, it is to be expected something like this, if the wind doesn't change again. A future native C# compiler was also mentioned at VS 2013 release keynote. -- Paulo Indeed. However, the difference is that, they're going public with it. I mean it's all well and good that they've built native C# compilers before ... but now they're going to let the little people play with one. I've followed native C# compilers since Spec# in Singularity 1. There has never been a real competitor to D that anybody outside of MSR could actually do anything with. That's really my whole point. But it's an important one. Now we have another option for a Safe, Efficient, Native language that you don't have to be a masochist to use. And it's going to evolve much faster than D... -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Microsoft working on new systems language
On 28.12.2013 16:43, Klaim - Joël Lamotte wrote: This is interesting but: - they don't talk about generic code? They use the same model of genericity as .NET, as explained on the original blog entry. - it's not clear if their language solves the build time issue C++ have (which D solves) Any language with proper module support solves this problem. C++ reliance on C toolchains is one reason of such issues. - if it's not a totally open language specification, then it's a dead-end to me. I don't care, my tool religion discussions are long gone and we use tools requested by customers anyway, not chosen by ourselves. -- Paulo
Re: Compiler hints, inlining and syntax consistency
On Sunday, 29 December 2013 at 11:02:33 UTC, Jacob Carlborg wrote: And my answer to that was probably something like: that module name could already be in use today. Can't remember :) It won't if such modules will used a common reserved package name (__dmd.attributes or __compiler.attributes). Also, then we get a third way of naming keywords: @property nothrow @reserved.foobar int bar (); Is it bad? Why would anyone want to qualify it explicitly? My proposal to resolve such name clash was to use existing symbol resolution rules and add explicit symbol import in such cases: import __compiler.attributes : property; // takes precedence over silent import AFAIK
Re: Microsoft working on new systems language
On Sunday, 29 December 2013 at 06:00:31 UTC, Adam Wilson wrote: I want to make a point here that many people come to do looking for something that is as performant as C++ with the ease of C# or Java, and for the most part (using LDC/GDC) you get exactly that. This language could convince me to go back to C#. I think neither Go, D or this language is as performant as (skilled use of) C/C++. If the background information is correct, this new language is aiming at safe concurrent programming. Just like Go. So they apparently use a scheme of making variables immutable and isolated and with all global variables immutable… I don't think you need to do that in all cases with transactional memory now available in new processors. Global variables are fast and easy for objects with few interdependencies, with near lock-free mechanisms in place, such as CAS and transactional memory, this is overkill in many scenarios. Simple, tight, unsafe, low-level memory-coherent designs tend to be faster. Guards as language-level-constructs, local storage etc, tend to be slower. But yes, I agree that this language could swipe the feet under D and Rust, Go is safe through its application domain. D really need some work in the low-level area to shine. D/Rust/Go/this-C#-language all claim to be system levels programming languages. I think they are not, as long as C/C++ is a better solution for embedded programming it will remain THE system level programming language. Which is kind of odd, considering that embedded systems would benefit a lot from a safe programming language (due to the cost/difficulty of updating software installed on deployed hardware). It doesn't matter if it is possible to write C++-like code in a language if the library support and knowhow isn't dominant in the ecosystem. (Like assuming a GC or trying too hard to be cross-platform).
Re: Bug report (sorry, couldn't register at bugzilla for some reason)
On Saturday, 28 December 2013 at 06:24:06 UTC, H. S. Teoh wrote: We should just call it a newsgroup. Or a mailing list. I prefer the latter, since it's clear that once the mail is sent out, you can't unsend it to make further corrections. Well, it does not really matter how we call it if domain is still forum.dlang.org ;)
Re: What is the rationale behind std.file.setAttributes ?
On 2013-12-29 12:00, Marco Leise wrote: Are you hijacking this thread to ask for Google Cloud support? ;) Don't forget FTP, SSH, WebDAV, ... Implementing all of this can take quite some time and will result in something like the Gnome virtual file-system. It might become so large that std.file is easily reimplemented as a tiny part of it for the native file-system module. Tango already contains a virtual file system interface. If I recall correctly it supports FTP and regular, local, file systems. -- /Jacob Carlborg
Re: Bug report (sorry, couldn't register at bugzilla for some reason)
Um yeah... I really don't mean to be disrespectful, but I don't think this is the place to discuss terminology.
Re: Tools should use the review process
On Saturday, 28 December 2013 at 20:44:10 UTC, Andrei Alexandrescu wrote: You know how it works - great tools for everyone originate as great tools for developers. Andrei There is a very practical concern in separation - end-user tools should be packages as part of compiler distribution. Right now I chose tools to add to Arch Linux `dlang-tools` package based on my own judgement. I'd prefer it to be standard obviously.
Re: Ehem, ARM
On 2013-12-28 23:21, Joakim wrote: I haven't completely grasped TLS and how it's done on OS X yet, but I get the sense I'll have to modify dmd a little to get TLS working with bionic. It appears that Martin and Johannes have looked into this before, so if you two have any feedback, let me know. Yes, you need to modify dmd. On Mac OS X every time a TLS variable is accessed the compiler inserts a call to ___tls_get_addr which is declared in rt.sections_osx in druntime. -- /Jacob Carlborg
Re: Tools should use the review process
On 2013-12-28 21:28, H. S. Teoh wrote: IMNSHO, I think the tools repo needs a reorg. Currently we have trivial things like 'changed' or 'findtags' or 'latest-tag', which are completely useless to everyone except the core devs (you probably don't even know what they're supposed to do unless you read the source code), and then we have 'dustmite' and 'rdmd' that generally applicable to whoever uses D. I think this needs to be split into two repos, one for production-quality tools that are meant for the end-user, and one for miscellaneous quick-hack scripts meant for internal use by the core devs. The current situation of dumping random stuff into tools that most people may or may not care for, 'cos we don't know where else to put them, only makes a laughing stock of D. Well said. It's most important to have a review for the end user tools. -- /Jacob Carlborg
Re: Compiler hints, inlining and syntax consistency
On 2013-12-28 21:12, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: Yes, well what I meant was that they used @ to avoid keyword clashes with the existing grammar. I personally feel like I am suffering when using Objective-C, it's like talking to a compiler with a split personality disorder. Yeah, but it has a though behind it and it's consistent at least. -- /Jacob Carlborg
Re: What is the rationale behind std.file.setAttributes ?
On 2013-12-29 11:36, Marco Leise wrote: Oh right, they have a hidden attribute as well. I guess if Phobos should expose the 'hidden' state of a file it should write to this attribute, but read both. E.g. for a file named .hidden you could do: attribs.hidden = false; and still assert(attribs.hidden == true); due to the POSIX file naming taking precedence then. Yeah, but that seems quite confusing. I don't know if it would be wise to use the same function for that. It would probably also be confusing if attribs.hidden = false renamed the file to remove the leading dot, if present. -- /Jacob Carlborg
Re: Compiler hints, inlining and syntax consistency
On 2013-12-28 22:07, Dicebot wrote: I have deja vu - remember talking with you about exactly this topic in NG several months ago :) Perhaps :) (My point was that it will still work if we make built-in attributes qualified with a reserved module name which is backwards-compatible change) And my answer to that was probably something like: that module name could already be in use today. Also, then we get a third way of naming keywords: @property nothrow @reserved.foobar int bar (); -- /Jacob Carlborg
Re: Tools should use the review process
On 2013-12-28 21:44, Andrei Alexandrescu wrote: You know how it works - great tools for everyone originate as great tools for developers. For some tools it's more obvious that they are benefit to both end users and core developers. See the post by H. S. Teoh: http://forum.dlang.org/thread/l9mmfd$1tte$1...@digitalmars.com#post-mailman.85.1388262606.15871.digitalmars-d:40puremagic.com -- /Jacob Carlborg
Re: Cross referencing in Ddoc
Am 31.12.2013 11:05, schrieb Vladimir Panteleev: P.S. How come your user agent (Thunderbird) is not emitting format=flowed messages? According to [1], it supports format=flowed, and can only be disabled via editing option strings. [1]: http://kb.mozillazine.org/Plain_text_e-mail_(Thunderbird)#Flowed_format Although I can't promise that I didn't tamper with these settings, I didn't find any non-default value in about:config in that area, but there is a default setting mailnews.send_plaintext_flowed = false. This is now manually set to true, let's see.
Re: Review of std.signal
On Thursday, 7 November 2013 at 13:45:57 UTC, Dicebot wrote:
Time to move forward with some more reviews :)
Hi,
Apologies, I missed this review thread. So, some questions /
observations:
IMO, the effort to disallow third parties to emit signals on
your object by far exceeds its worth.
For this purpose, you have needed:
- string mixins
- ...which declare, by convention, a field with a name not
explicitly given by the user
- ...with a workaround for when they don't work
- an enumeration type
- two different signal struct types
- a boatload of documentation
- a nontrivial cognitive effort on the user to grok all of the
above
This little feature steals too much focus, and IMO is not worth
it.
As a compromise, have you considered template mixins?
mixin template M()
{
public void pub() {}
private void pri() {}
}
struct S
{
mixin M m;
}
Trying to access S.m.pri() from another module fails as expected.
The downside is that the .m is not required, so the mixin
members will spill over the parent object's field namespace.
This implementation supersedes the former std.signals
I don't think comparisons of older versions of a module belong in
the module's documentation.
a.valueChanged.connect!watch(o);// o.watch is the slot
This is really ugly, but I don't see any way to improve it
either. Maybe if the type of classInstance.method was actually a
special pointer-to-class-method type that implicitly
down-casted to a delegate, it would be possible to safely use
o.watch instead...
dg must not be null. (Its context may.)
I don't think the context will ever be null (unless you take the
address of a null class/struct pointer's method). (toDelegate
uses the context pointer to store the function pointer, and the
function pointer to store a template instance according to the
function's arguments.)
It implements the emit function for all other functionality it
has this aliased to RestrictedSignal.
Missing some punctuation, I think.
The idea is to instantiate a Signal privately and provide a
public accessor method for accessing the contained
RestrictedSignal.
I had a hard time understanding this line the first time. Please
reword without using The idea is, because it's not clear what
the idea is for - usage? Rationalization of implementation
method?
Use this overload if you either really, really want strong ref
semantics for some reason
Was the emphasis really necessary? It makes complete sense to
build an asynchronous-event-model application using 100% only
strong connections (delegates or delegate arrays). I don't
remember ever NEEDING weak-referenced callbacks.
Re: Is it possible for the deimos repositories to be added to the dub registry please?
On Monday, 6 January 2014 at 09:52:53 UTC, Jacob Carlborg wrote: On 2014-01-05 21:57, Kelet wrote: A lot of Deimos repositories are already in the DUB registry. I think we should close down Deimos now that we have Dub. Who currently controls deimos?
Re: Microsoft working on new systems language
On Tuesday, 31 December 2013 at 00:45:51 UTC, Adam D. Ruppe wrote: On Tuesday, 31 December 2013 at 00:21:21 UTC, Ola Fosheim Grøstad wrote: Maybe I misunderstand, but isn't the purpose of std.allocator to set up allocators that new can call into? No, it'll be a standard library interface. I really think the built-in new should be discouraged - it has a lot of disadvantages over using a library setup, and not many advantages. I suspect it will still be fine to use in situations where a loose aliasing policy is required (so GC-exclusive characteristics are depended on), such as scripts and certain other application code. The same goes for using the concatenation operators, over `Appender` et al. with a pluggable allocator. For libraries though - definitely should be a red flag.
Re: Microsoft working on new systems language
On Sunday, 29 December 2013 at 13:46:07 UTC, Dicebot wrote: This is not true. Assuming skilled use and same compiler backend those are equally performant. D lacks some low-level control C has (which is important for embedded) but it is not directly related to performance. That low-level control also matters for performance, when you have hard deadlines. E.g. when the GC kicks in, it not only hogs all the threads that participate in GC, it also trash the caches unless you have a GC implementation that bypasses the caches. Sustained trashing of caches is bad. C has low-level, low resource usage defaults. While you can do the same in some other languages they tend to default to more expensive use patterns. Like D defaults to stuff like GC and thread-local-storage. Defaults affect library design, which in turn affect performance. (thread local storage requires either an extra indirection through a register or multiple kernel level page tables per process)
Re: Review of std.signal
On Monday, 6 January 2014 at 10:13:44 UTC, Vladimir Panteleev wrote: Apologies, I missed this review thread. =/ Any good idea to make those more visible? Maybe we should setup a mailing list for those who want to be notified about ongoing reviews?
Re: std.conv.parse for user defined structs/objects
06-Jan-2014 08:19, H. S. Teoh пишет:
On Fri, Dec 27, 2013 at 08:43:25PM +, Ilya Yaroshenko wrote:
I've been thinking about this too. It shouldn't be too hard to add
this to std.conv (I'd call it fromString, though, by analogy with
toString -- parseImpl looks a bit ugly).
Is fromString good in case of InputRange?
Good point. Maybe parse?
Parse from an input range... That's going to be tricky and inefficient.
class T {
static T parse(R)(R inputRange)
if (is(ElementType!R : dchar))
{
T result;
... // parse inputRange
return result;
}
}
T
--
Dmitry Olshansky
Re: Understanding and new language feature proposal
This is a great syntax and I am doing this :p. But there are many many many many issues associated with this (I mentioned that I wanted them natively, templates are problems). The library needed a significant coding and still to match with immutable, support from phobos - it is tough. C++ also has some of these implementation (SystemC) - but that did not made it acceptable to embedded systems programmer. Again a library will not allow me to extract last drop from my HW - for every library and everybody :). The internal implementation of these libraries are memory hungry and not embedded systems friendly. Regards, Sumit On Monday, 6 January 2014 at 09:41:12 UTC, bearophile wrote: Sumit Adhikari: unsigned bits(179:0) a ; unsigned bits(179:0) b ; unsigned bits(179:0) result = a + b ; What about this syntax: UnsignedBits!(179, 0) a, b; UnsignedBits!(179, 0) result = a + b; Or better: alias ubits = UnsignedBits!(179, 0) ubits a, b; ubits result = a + b; Bye, bearophile
Re: Graphics Library for D
On 2014-01-06 05:10, Adam Wilson wrote: Hello Fellow D Heads, Recently, I've been working to evaluate the feasibility and reasonability of building out a binding to Cinder in D. And while it is certainly feasible to wrap Cinder, that a binding would be necessarily complex and feel very unnatural in D. So after talking it over with Walter and Andrei, we feel that, while we like how Cinder is designed and would very much like to have something like it available in D, wrapping Cinder is not the best approach in the long-term. With that in mind, we would like to start a discussion with interested parties about building a graphics library in the same concept as Cinder, but using an idiomatic D implementation from the ground up. Walter has suggested that we call it Aurora, and given the visual connotations associated with that name, I think it is most appropriate for this project. [SNIP] So with the above framework in mind, let's talk! I like it :). Every time I read a proposal that has anything to do with graphics I always start to think there will be problems on Mac OS X. Depending on how much interaction with the platform is needed, it always comes back to the same problem: interfacing with Objective-C. It's verbose, cumbersome and annoying to interface with Objective-C without language support. We badly need D/Objective-C [1]. [1] http://wiki.dlang.org/DIP43 -- /Jacob Carlborg
Re: case insensitive flag not working with replaceAll
Thanks for the response and assistance. I was using the function incorrectly, I/O error ;).
Re: Compile time executable calling?
On 2014-01-09 00:16, H. S. Teoh wrote: offtopic rant A *shell script* could do better than make, by actually making sure that everything is recompiled and up-to-date I use a shell script for most of my projects. It's usually a one line shell script, just to not have to retype all flags every time. The fact that `make clean` exists at all, is a testament to just how broken the whole thing is (and the saddest thing is that `make clean` has come to be accepted as a part of life, when it shouldn't even exist in the first place, had build systems been designed correctly to begin with). What if you change the makefile, say adding a flag? That flag might require the whole project to be rebuilt. How should that be handled automatically? Always to a full rebuild if the makefile has been changed? -- /Jacob Carlborg
Re: [RFC] I/O and Buffer Range
06-Jan-2014 09:41, Jason White пишет:
On Sunday, 5 January 2014 at 13:30:59 UTC, Dmitry Olshansky wrote:
I my view text implies something like:
void write(const(char)[]);
size_t read(char[]);
And binary would be:
void write(const(ubyte)[]);
size_t read(ubyte[]);
Should not clash.
Those would do the same thing for either text or binary data. When I say
text writing, I guess I mean the serialization of any type to text (like
what std.stdio.write does):
void write(T)(T value); // Text writing
void write(const(ubyte)[] buf); // Binary writing
write([1, 2, 3]); // want to write [1, 2, 3]
// but writes \x01\x02\x03
This clashes. We need to be able to specify if we want to write/read a
text representation or just the raw binary data. In the above case, the
most specialized overload will be called.
Ok, now I see. In my eye though serialization completely hides raw
stream write.
So:
struct SomeStream{
void write(const(ubyte)[] data...);
}
struct Serializer(Stream){
void write(T)(T value); //calls stream.write inside of it
private:
Stream stream;
}
In-memory array IMHO better not pretend to be a stream. This kind of
wrapping goes in the wrong direction (losing capabilities). Instead
wrapping a stream and/or array as a buffer range proved to me to be
more natural (extending capabilities).
Shouldn't buffers/arrays provide a stream interface in addition to
buffer-specific operations?
I think it may be best not to. Buffer builds on top of unbuffered
stream. If there is a need to do large reads it may as well use naked
stream and not worry about extra copying happening in the buffer layer.
I need to think on this. Seeing as lookahead + seek could be labeled as
read even though it's not.
I don't see why it would conflict with a
range interface. As I understand it, ranges act on a single element at a
time while streams act on multiple elements at a time. For ArrayBuffer
in datapicked, a stream-style read is just lookahead(n) and cur += n.
What capabilities are lost?
In short - lookahead is slicing, read would be copying.
For me prime capability of an array is slicing that is dirt cheap O(1).
On the other hand stream interface is all about copying bytes to the
user provided array.
In this setting it means that if you want to wrap array as stream, then
it must follow generic stream interface. The latter cannot and should
not think of slicing and the like. Then while wrapping it in some
adapter up the chain it's no longer seen as array (because adapter is
generic too and is made for streams). This is what I call capability loss.
If buffers/arrays provide a stream interface, then they can be used by
code that doesn't directly need the buffering capabilities but would
still benefit from them.
See above - it would be better if the code was written for ranges not
streams. Then e.g. slicing of buffer range on top of array works just as
cheap as it was for arrays. And zero copies are made (=performance).
Currently, std.stdio has all three of
those facets rolled into one.
Locking though is a province of shared and may need a bit more thought.
Locking of streams is something that I haven't explored too deeply yet.
Streams that communicate with the OS certainly need locking as thread
locality makes no difference there.
Actually these objects do just fine, since OS does the locking (or makes
sure of something equivalent). If your stream is TLS there is no need
for extra locking at all (no interleaving of I/O calls is possible)
regardless of its kind.
Shared instances would need locking as 2 threads may request some
operation, and as OS locks only on per sys-call basis something cruel
may happen in the code that deals with buffering etc.
--
Dmitry Olshansky
Re: Understanding and new language feature proposal
Just a twist : unsigned bits(179:0) a ; unsigned bits(179:0) b ; unsigned bits(190:0) result = a + b ; OR unsigned bits(108826676:0) result = a + b ; Regards, Sumit On Monday, 6 January 2014 at 09:41:12 UTC, bearophile wrote: Sumit Adhikari: unsigned bits(179:0) a ; unsigned bits(179:0) b ; unsigned bits(179:0) result = a + b ; What about this syntax: UnsignedBits!(179, 0) a, b; UnsignedBits!(179, 0) result = a + b; Or better: alias ubits = UnsignedBits!(179, 0) ubits a, b; ubits result = a + b; Bye, bearophile
Re: Is it possible for the deimos repositories to be added to the dub registry please?
On 2014-01-06 11:29, Gary Willoughby wrote: Who currently controls deimos? The D core team. -- /Jacob Carlborg
Re: Hitchikers Guide to Porting Phobos / D Runtime to other architectures
On 2014-01-08 16:25, Johannes Pfau wrote: The compiler can not know that a struct isn't used/void initialized. With separate compilation TypeInfo is output in object A.o and could be used from any other object. So only the linker actually knows for sure if the TypeInfo is used (There are exceptions where even the linker can't know that. Think of dynamic libraries). Right, separate compilation always ruins the day :( -- /Jacob Carlborg
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Thursday, 9 January 2014 at 10:14:08 UTC, Benjamin Thaut wrote: If requested I can make a list with all language features / decisions so far that prevent the implementation of a state of the art GC. At least I am interested in your observations.
Re: GuitarHero/RockBand fans... side project anyone?
On 2014-01-09 00:27, Manu wrote: I guess, but I've always managed to stuff up sub-module references in the past :) Is it possible to make a submodule reference the remote head, rather than a particular revision? Have a look at this: http://stackoverflow.com/questions/9189575/git-submodule-tracking-latest If/when other people are involved, then they are welcome to make improvements to the project setup. Just let me get an interesting/hackable shell first ;) Fair enough :) -- /Jacob Carlborg
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
Am 09.01.2014 08:07, schrieb Walter Bright: The point is, no matter how slow the GC is relative to malloc, not allocating is faster than allocating, and a GC can greatly reduce the amount of alloc/copy going on. The points should be, if D is going to stay with a GC, and if so, when we will actually get propper GC support so a state of the art GC can be implemented. Or if we are going to replace the GC with ARC. This is a really important topic which shouldn't wait until the language is 20 years old. I'm already using D since almost 3 years, and the more I learn about Garbage Collectors and about D, the more obvious becomes that D does not properly support garbage collection and it will require quite some effort and spec changes to do so. And in all the time I used D nothing changed about the garbage collector. The only thing that happend was the RtInfo template in object.d. But it still isn't used and only solves a small portion of the percise scanning problem. In my opinion D was designed with language features in mind that need a GC, but D was not designed to actually support a GC. And this needs to change. If requested I can make a list with all language features / decisions so far that prevent the implementation of a state of the art GC. -- Kind Regards Benjamin Thaut
Re: Where is contribution most needed to the D community?
On 2014-01-09 08:45, Kira Backes wrote: Dear D users, after a long time evaluating all options I think I finally committed to D and vibe.d! Since I’ll have a lot of memory usage and I want to do an MMORPG I always was scared off by GC-enabled languages, but after thoroughly evaluating what this language (and vibe.d) gives me in terms of performance, memory usage (this is especially important, a lot of GC-languages like Java have unacceptable memory bloat for objects etc.) and productivity I think this is the best decision. Obviously I’ll have some work to do later to move most of the objects out of the GC (they usually live from the start of the server to the end of the server) but I now thinks that this work is still a lot less then all the other work combined. I especially like the built-in contract programming, invariants and unit-tests and I think they’ll be worth a lot! And even more awesome is the compile-time reflection for serialization (very important for my projects). So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog? We could use some help with all of those. It's hard to choose. -- /Jacob Carlborg
Re: Graphics Library for D
On 2014-01-08 19:39, David Gileadi wrote: I think if you're willing to use version 2.4 then you get a much more permissive license, no? That's how I read http://www.antigrain.com/license/index.html anyway... Looks like it's less permissive than the Boost license due to point 2. -- /Jacob Carlborg
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Thursday, 9 January 2014 at 09:58:24 UTC, Walter Bright wrote: Please explain how this can work passing both string literals and allocated strings to cat(). By having your own string allocator that tests for membership when you free (if you allow free and foreign strings in your cat)? How do you return a string that is the path part of a path/filename? (The terminating 0 is not a problem solved by creating your own allocator.) If you discard the original you split at '/'. If you use your own stringallocator you don't have to worry about free... You either let the garbage remain until the pool is released or have a separate allocation structure that allows internal splits (no private size info before first char).
Re: Review of std.signal
On Monday, 6 January 2014 at 10:39:41 UTC, Dicebot wrote: On Monday, 6 January 2014 at 10:13:44 UTC, Vladimir Panteleev wrote: Apologies, I missed this review thread. =/ Any good idea to make those more visible? Maybe we should setup a mailing list for those who want to be notified about ongoing reviews? Yes, I also think that we should have separate mailing list for reviews and votings. At least, it will be easier to find previous reviews.
Re: Where is contribution most needed to the D community?
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote: Dear D users, after a long time evaluating all options I think I finally committed to D and vibe.d! Since I’ll have a lot of memory usage and I want to do an MMORPG I always was scared off by GC-enabled languages, but after thoroughly evaluating what this language (and vibe.d) gives me in terms of performance, memory usage (this is especially important, a lot of GC-languages like Java have unacceptable memory bloat for objects etc.) and productivity I think this is the best decision. Obviously I’ll have some work to do later to move most of the objects out of the GC (they usually live from the start of the server to the end of the server) but I now thinks that this work is still a lot less then all the other work combined. I especially like the built-in contract programming, invariants and unit-tests and I think they’ll be worth a lot! And even more awesome is the compile-time reflection for serialization (very important for my projects). So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog? Please tell me what you think! :-) rgds, Kira Backes A good web service stack is the main thing for Vibe I believe. Because of this I started Cmsed (I'll push it into repo soon) a component library that also functions as a content management system. I also built and still working on an ORM (Dvorm [0]). I need OpenDBX support for e.g. Mysql added to it. I have bindings to it available. Mongo already supported. There is also standards like odata I wish to support with my router natively. For this I need some sort of relationship system within Dvorm. I strongly believe some sort of GWT [1] inspired system is also required to work alongside a router. I did have this planned for DOOGLE [2] but since talk about a new gui base system, there's little point in me continuing it. But from a practical side. We need articles showing good examples of simple code to do awesome stuff. Benchmarks on memory/cpu usage ext. Also very important. At the end of day, choose what you're good at and love. It'll help no matter what it is :) [0] https://github.com/rikkimax/Dvorm [1] http://www.gwtproject.org/ [2] https://github.com/rikkimax/DOOGLE
Re: Should this work?
On 2014-01-09 18:20, Manu wrote: That's great and all, but it's no good if I have to pay for it (time and money!) even when that's not a requirement. I'm dealing with ascii right now. There are couple of functions in std.ascii but not what you needed here. -- /Jacob Carlborg
Re: Should this work?
Am 09.01.2014 15:07, schrieb Manu: On a side note, am I the only one that finds std.algorithm/std.range/etc for string processing really obtuse? I can rarely understand the error messages, so say it's better than STL is optimistic. Using std.algorithm and std.range to do string manipulation feels really lame to me. I hate looking through the docs of 3-4 modules to understand the complete set of useful string operations (std.string, std.uni, std.algorithm, std.range... at least). I also find the names of the generic algorithms are often unrelated to the name of the string operation. My feeling is, everyone is always on about how cool D is at string, but other than 'char[]', and the builtin slice operator, I feel really unproductive whenever I do any heavy string manipulation in D. I also hate that I need to import at least 4-5 modules to do anything useful with strings... I feel my program bloating and cringe with every gigantic import that sources exactly one symbol. I feel exactly the same. C# has way more utility functions that are named in a way that actually helps you understand what they do. The best example in D is the deprection of indexOf. Now you have to call countUntil. But if I have to choose between the two names, indexOf actually tells me what it does, while countUntil does not. count until what? The confusion mostly comes from the condition which is a template argument with default value. Not to speak of the issues with UTF8 characters, where countUntil does not actually give you a index into the array, but actually gives you the index of the character it found. So you can't use whatever comes out of countUntil for slicing. -- Kind Regards Benjamin Thaut
Re: another cool RTInfo trick - i want in runtime
On Thursday, 16 January 2014 at 18:44:54 UTC, Namespace wrote:
I guess that could work pretty well for a C++ friend emulation
with UDA's! Were not you the one who wanted to show me an
example for that with using RTInfo?
I've played with rtinfo a lot before, but I don't remember doing
C++ friend emulation...
Offer your way the possibility to check automatically for null
references? With an UDA e.g. @safe_ref or @not_null
I think those would be better done with the type info, like
NotNull!t.
What's cool about the RTInfo thing though is it is checked on
everything, so it can check for the *absence* of a UDA as well as
for the presence.
You might say something must not have any nullable references
unless specially marked. The rtinfo checker can confirm that:
loop over all members, if it is potentially nullable and isn't
marked with either NotNull or
@i_know_this_is_nullable_and_that_is_ok, it can throw an error.
It is possible to do that kind of thing with static assert on the
module level too sort of. See, the module level one for one
can be forgotten and it can't access nested things in functions:
void foo() {
struct InnerStruct {}
}
// can't see foo.InnerStuct here!
static assert(ModulePassesCheck!(mixin(this_module)));
But RTInfo *does* see InnerStruct, and you don't have to remember
to add the check to your module too.
Re: Where is contribution most needed to the D community?
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote: Dear D users, after a long time evaluating all options I think I finally committed to D and vibe.d! Since I’ll have a lot of memory usage and I want to do an MMORPG I always was scared off by GC-enabled languages, but after thoroughly evaluating what this language (and vibe.d) gives me in terms of performance, memory usage (this is especially important, a lot of GC-languages like Java have unacceptable memory bloat for objects etc.) and productivity I think this is the best decision. Obviously I’ll have some work to do later to move most of the objects out of the GC (they usually live from the start of the server to the end of the server) but I now thinks that this work is still a lot less then all the other work combined. I especially like the built-in contract programming, invariants and unit-tests and I think they’ll be worth a lot! And even more awesome is the compile-time reflection for serialization (very important for my projects). So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog? Please tell me what you think! :-) rgds, Kira Backes Hi and welcome here, It's hard to tell what is most important. I feel that these days dub is an enabling project that deserves some help.
Re: A strongly pure PRNG
On Tuesday, 7 January 2014 at 12:37:39 UTC, qznc wrote: On Tuesday, 7 January 2014 at 12:32:23 UTC, Kagamin wrote: I believe, bearophile was interested in this - a strongly pure immutable Xorshift32(1) PRNG: http://dpaste.dzfl.pl/5f710daf I would consider this weakly pure, because the implicit parameter this is not immutable. A strongly pure PRNG cannot change internal state. Formally it is immutable, see line 36.
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
And, if it isn't in D already I would very much like to have a weak pointer type that will be set to null if the object is only pointed to by weak pointers. It is a PITA to have objects die and get them out of a bunch of event-queues etc.
Re: Non-null objects, the Null Object pattern, and T.init
On 1/17/2014 7:38 PM, Walter Bright wrote:
But I agree that compile time
detect of null reference bugs is better than runtime detection of them.
BTW, the following program:
class C { int a,b; }
int test() {
C c;
return c.b;
}
When compiled with -O:
foo.d(6): Error: null dereference in function _D3foo4testFZi
It isn't much, only working on intra-function analysis and only when the
optimizer is used, but it's something. It's been in dmd for a long time.
Re: Does the dub registry at code.dlang.org have problems?
Am 10.01.2014 19:18, schrieb Brad Roberts: OAuth is only needed if you need to perform actions as someone else. Otherwise your own account creds are sufficient to be able to do 5000 queries an hour rather than the unauth'ed limit of 60 an hour. Good to know, I'll create a dummy account and test/implement that when I get some time (and nobody beats me to it ;)
Re: Non-null objects, the Null Object pattern, and T.init
Jacob Carlborg wrote in message news:lbdkvv$2f1n$1...@digitalmars.com... Why only when the optimizer is used? The code that detects the null dereference is in the optimizer.
Re: Is rcc.exe available for download?
On Wednesday, 20 October 2004 at 17:43:29 UTC, John Reimer wrote: Lynn Allan wrote: I'm attempting to build SDWF sample code. The makefile attempts to invoke rcc.exe. Is this available for free download? Yep, see http://www.digitalmars.com/download/freecompiler.html rcc.exe is within the Basic utilities archive. Either the link for dup.zip is compromised or Trendmicro flag it as dangerous incorrectly. Are the sources available?
Re: Optional tags and attributes
On 2014-01-18 04:02, Steven Schveighoffer wrote:
I think a use the attributes of X would be a general enough tool.
Something like:
void thisIsSoPolymorphic() attrOf(T.foo)
Yet another case for AST macros:
class Careful (T)
{
void thisIsSoPolymporphic () @inferAttributes(T.foo) { }
}
macro inferAttributes (Context context, Ast!(Symbol) symbol, Declaration
decl)
{
foreach (attr ; symbol.attributes)
decl.attributes ~= attr;
return decl;
}
--
/Jacob Carlborg
Re: Non-null objects, the Null Object pattern, and T.init
On Saturday, 18 January 2014 at 03:07:30 UTC, H. S. Teoh wrote: You missed his point. The complaint is that the car has a *single* software system that handles everything. That's a single point of failure. When that single software system fails, *everything* fails. I didn't miss the point at all. My point is that you should always target the cost of improving the statistical overall safety of the system rather than optimizing the stability of a single part that almost never fail. Having multiple independent software implementations only works for very simple systems. And in that case you can prove correctness by formal proofs. It is more likely to fail due to a loose wire or electrical components.
Re: Non-null objects, the Null Object pattern, and T.init
On 2014-01-18 07:10, Walter Bright wrote:
BTW, the following program:
class C { int a,b; }
int test() {
C c;
return c.b;
}
When compiled with -O:
foo.d(6): Error: null dereference in function _D3foo4testFZi
It isn't much, only working on intra-function analysis and only when the
optimizer is used, but it's something. It's been in dmd for a long time.
Why only when the optimizer is used?
--
/Jacob Carlborg
Re: Non-null objects, the Null Object pattern, and T.init
Tobias Pankrath wrote in message news:rxnlyzyfkzndzfslv...@forum.dlang.org... Why is it located there? It's probably flow sensitive and only the optimizer builds a CFG. Exactly. It _could_ be done in the frontend, but it hasn't.
Re: Non-null objects, the Null Object pattern, and T.init
On 2014-01-18 11:41, Daniel Murphy wrote: The code that detects the null dereference is in the optimizer. Why is it located there? -- /Jacob Carlborg
Re: Non-null objects, the Null Object pattern, and T.init
On Saturday, 18 January 2014 at 11:03:22 UTC, Jacob Carlborg wrote: On 2014-01-18 11:41, Daniel Murphy wrote: The code that detects the null dereference is in the optimizer. Why is it located there? It's probably flow sensitive and only the optimizer builds a CFG.
Re: Non-null objects, the Null Object pattern, and T.init
On Saturday, 18 January 2014 at 06:10:20 UTC, Walter Bright wrote:
On 1/17/2014 7:38 PM, Walter Bright wrote:
But I agree that compile time
detect of null reference bugs is better than runtime detection
of them.
BTW, the following program:
class C { int a,b; }
int test() {
C c;
return c.b;
}
When compiled with -O:
foo.d(6): Error: null dereference in function _D3foo4testFZi
It isn't much, only working on intra-function analysis and only
when the optimizer is used, but it's something. It's been in
dmd for a long time.
But:
class C { int a, b; }
C create() pure nothrow {
return null;
}
int test() pure nothrow {
C c = create();
return c.b;
}
void main() {
test();
}
Print nothing, even with -O.
Maybe the idea to use C? for nullable references would be worth
to implement.
Re: Non-null objects, the Null Object pattern, and T.init
On 1/18/2014 2:02 AM, Namespace wrote: Print nothing, even with -O. Right. As I explained, it is only intra-function analysis.
Re: GPGPUs
On Sunday, 18 August 2013 at 18:35:45 UTC, Russel Winder wrote: https://github.com/Trass3r/cl4d I had missed that as well. Bad Google and GitHub skills on my part clearly. I think the path is now obvious, ask if the owner will turn this repository over to a group so that it can become the focus of future work via the repositories wiki and issue tracker. I will fork this repository as is and begin to analyse the status quo wrt the discussion recently on the email list. Interesting. I discovered this thread via the just introduced traffic analytics over at Github ^^ Haven't touched the code for a long time but there have been some active forks. I've been thinking to offer push rights to them for quite a while but never got around to it.
Re: Non-null objects, the Null Object pattern, and T.init
On 2014-01-17 21:42, Michel Fortin wrote: Andrei's post was referring at language/compiler changes too: allowing init to be defined per-class, with a hint about disabling init. I took the hint that modifying the compiler to add support for non-null was in the cards and proposed something more useful and less clunky to use. Hehe, right, I kind of lost track of the discussion. -- /Jacob Carlborg
Re: Non-null objects, the Null Object pattern, and T.init
On 1/18/2014 2:28 AM, Jacob Carlborg wrote: Why only when the optimizer is used? Yes, because the optimizer uses data flow analysis, and this falls out of that.
Re: Non-null objects, the Null Object pattern, and T.init
On 2014-01-18 12:21, Daniel Murphy wrote: Exactly. It _could_ be done in the frontend, but it hasn't. I see, thanks. -- /Jacob Carlborg
Re: Non-null objects, the Null Object pattern, and T.init
On 2014-01-18 03:38:31 +, Walter Bright newshou...@digitalmars.com said: On 1/17/2014 7:23 PM, Michel Fortin wrote: I guess so. But you're still unconvinced it's worth it to eliminate null dereferences? I think it's a more nuanced problem than that. But I agree that compile time detect of null reference bugs is better than runtime detection of them. In the C++ project I'm working on (full of asynchronous callbacks) I've built myself a not-null smart pointer type. It tries to disallow things at compile time, but because it can't follow control flow there's obviously some possible leaks that are caught at runtime through an assertion upon assignment. I created it because I had some untraceable bugs and I though it'd be simpler to convert the code base to use not-null pointers than it'd be to narrow the issues manually. The transition was surprisingly easy: just try to make everything you can not-nullable. Sometime the logic forces you to make a variable nullable, sometime you discover a bug in the form of a missing null check. Implementing non-nullable pointers and adapting the code base was worth it for me. I found some bugs that I couldn't track otherwise, and some others that had yet to occur. But more importantly now when I look at a pointer in this project I know immediately from its declaration whether that pointer can be null or not, and I find that very helpful when tweaking code that was written a while ago. But in the process I've created a new meta-language (make_new T instead of new, a new smart pointer types, cast function for those pointers, etc.) that someone new on the project will have to learn and train himself to use correctly. Integrating the thing in the language would make things that much simpler because it'd preserve the normal syntax of the language and also because null leaks can all be detected at compile-time, with clearer error messages. This is what motivated my proposal earlier in this thread. I'm proposing an improved version of what I'm already using currently: http://forum.dlang.org/thread/lba1qe$1sih$1...@digitalmars.com?page=4#post-lbbgr6:247sf:241:40digitalmars.com I'd like to know what you think of it. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: SHA-3 is KECCAK
On Friday, 17 January 2014 at 14:53:04 UTC, Chris Cain wrote: Your first part is true, but the second part is not. A generic collision attack can cause issues depending on what you're trying to do. For general use, MD5 is not safe enough based on that alone. No technology is safe, and SHA3 doesn't solve this problem. Cryptography is particularly not fool-proof. Remember issues in RSA? The factorization math behind it is bulletproof, yet, it's still considered hackable. The wikipedia article on MD5 covers this reasonably well enough: http://en.wikipedia.org/wiki/MD5 Do note that SHA1 is similar enough to MD5 that many are recommending against SHA1 as well (and I recommend following that advice). It's not as broken as MD5 but since we have SHA2 there's no good reason not to use the better version. For general messages requiring any degree of security against an attacker, use SHA2 (this does not necessarily apply to hashing passwords which have their own concerns, obviously). Stay away from MD5 and no new projects should use SHA1 (although my understanding is that no one is saying jump from the ship for SHA1 right now). These are generally accepted practices in the cryptography community. If you want to roll the dice with MD5, by all means, but don't spread acceptance of MD5 because someone might follow your advice against the clear recommendations of the cryptography community. As far as I'm concerned, it's unethical to recommend MD5 for security purposes at this point. Ethics don't help in cryptography, only real factors play role. Your insistence on blind following to recommendations and expecting them to magically protect security - by encouraging thoughtless behavior such voodooism is way more troublesome. SHA3 is just more convenient than MD5 because when you want to change the hash function, you don't have to ditch the whole system, only change its parameters. I'm sorry but no. The reason we wanted a SHA3 is because we needed a message digest algorithm that is different enough from MD5, SHA1, and SHA2 so that an attack discovered on those algorithms should not be applicable to SHA3 as well (as was the case with MD5 and SHA1). The things you describe are just bonuses. This works both ways: an attack on SHA3 doesn't affect other hash functions. The older algorithms are more trustworthy exactly because they are well studied, have no dark corners and evolve gradually by fixing discovered weaknesses. That's rather inconvenient, that you can't have an efficient implementation of the algorithm on common hardware. MD5 family has no such flaw. You seem to not know enough about this topic to discuss it. SHA3 is fast on common hardware, as it is designed. Specialized hardware can be made and that's fine, intentional, and even beneficial. Most cryptography is designed that way. DES was, AES is (AES instructions exist on many modern hardware, in fact), and SHA3 is as well. This is not a flaw and if you think it is, go talk with cryptographers instead of me because you're clearly well beyond my skill level (that said, since you're discussing the viability of MD5, you're not anywhere close to as competent on this matter as you think you are, no offense). It's even worse that new algorithms force hardware vendors to add specialized instructions which are of no use for other software. On Friday, 17 January 2014 at 15:13:27 UTC, Chris Cain wrote: On Friday, 17 January 2014 at 14:04:29 UTC, Kagamin wrote: There's no successful preimage attack on MD5, which is the only deadly attack on a hash function. For one amusing example of why MD5 is broken (from years ago using a video game console, of all things), consider: http://www.win.tue.nl/hashclash/Nostradamus/ They didn't predict the result of elections, not sure what you want to prove by a lie.
Re: SHA-3 is KECCAK
On Saturday, 18 January 2014 at 12:48:28 UTC, Kagamin wrote: ..snip almost everything.. I'm not going to be doing this. Everything you say suggests you have no clue about anything about cryptography and you're going to be bit sooner rather than later. Don't spread your information, just keep it to yourself so that the damage is limited. Thanks. They didn't predict the result of elections, not sure what you want to prove by a lie. You're correct. It was an example of a collision attack which means they can put up a single hash and it will match many possible documents that include all the names of the candidates. If you had _read_ the source, you may have understood that. In fact, if you have read anything on cryptography at all before, you'd be staying away from MD5, but ignorance is bliss I suppose. Just don't spread your ignorance to others because you could easily cost people their livelihood. If you lose your job because of this, then that's on you, so I won't feel badly about it. But I am concerned about an innocent third party walking in thinking you might have a clue of what you're talking about, when you clearly don't. Take care.
Re: Non-null objects, the Null Object pattern, and T.init
On Saturday, 18 January 2014 at 00:44:56 UTC, Ola Fosheim Grøstad wrote: Big systems have to live with bugs, it is inevitable that they run with bugs. Erlang was created for stuff like that. Can you imagine a telephone central going down just because the settings for one subscriber was wrong and triggered a bug? Stupid me, that I thought that all this mess was solved decades ago with the CPU protected mode. I tend to agree with Walter on this front. -- Paolo
Re: Programmer en D published on dlang-fr.org
Le 16/01/2014 18:34, sclytrack a écrit : On Wednesday, 15 January 2014 at 20:19:51 UTC, Raphaël Jakse wrote: Le 15/01/2014 21:18, Raphaël Jakse a écrit : Fixes can come from the ***support*** you are the most at ease, it's ok for me media might be a better word ;-) Le petit travail pour ce soir. :-) Appuyer avec le souris sur voir les passages http://dlang-fr.org/cours/programmer-en-d/compilateur.html http://dlang-fr.org/cours/programmer-en-d/types.html http://dlang-fr.org/cours/programmer-en-d/variables.html ifloat, cfloat ... needs to be removed from the original English version. I might have an issue with the following phrase where a verb equals a noun. Introducing a variable to the program is called its definition. http://dlang-fr.org/cours/programmer-en-d/es.html http://dlang-fr.org/cours/programmer-en-d/expression_logiques.html expressions logiques http://dlang-fr.org/cours/programmer-en-d/corrections/expressions_logiques.html Revenir au chapitre: Expressions logiques Oops! That page can’t be found. Merci, j'ai tout corrigé ;-) J'ai par contre laissé la partie sur les imaginaires. Peut-être qu'on devrait en discuter avec Ali et toi avant de faire quoi que ce soit.
CMake script for dmd source
Has anyone ever created a CMakeLists.txt for the dmd source?
Re: SHA-3 is KECCAK
On Friday, 17 January 2014 at 15:00:38 UTC, Chris Cain wrote: On Friday, 17 January 2014 at 14:06:57 UTC, Kagamin wrote: Doesn't TCP take care of that? For a packet, yes. In general you can assume that if a transfer completes under TCP then it is very likely correct. That's the way TCP is designed. If you want to check the entire file at the end, MD5 could theoretically be done as a sanity check. I'd still use SHA-2 (in the form of a digital signature, obviously) minimally if your intention is to ensure it hasn't been tampered with It's hard and expensive to use digital signatures in public projects and doesn't protect from tampering. In fact, direct tampering in such setup is cheaper than a collision attack, not even speaking, that a collision attack doesn't work here, only a preimage attack.
Re: Non-null objects, the Null Object pattern, and T.init
On 2014-01-17 17:52:18 +, Yota yot...@thatgooglemailthing.com said: On Friday, 17 January 2014 at 15:05:10 UTC, Michel Fortin wrote: Couldn't we just add a class declaration attribute that'd say that by default this type is not-null? I have been hoping D would become not-null-by-default since I discovered the language. Looking at what it has done with other type classes, (shared, immutable, etc) it always seemed like something that would be right up its alley. However in my dream world, it would simply apply to all reference types by default. Well, nothing prevents that from happening if @notnull is adopted. As proposed, @notnull is designed to keep the language backward compatible: it's opt-in and you don't even have to opt-in all at once. Potential problems the early implementation might have can only burn those who give it a try. One can hope the feature will become so loved that it'll become standard pointer behaviour one day, but that can't happen as long as the feature is theoretical. In the eventuality we decide one day to push not-null behaviour to the rest of the language, @notnull will just become an attribute with no effect. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Programmer en D published on dlang-fr.org
On 01/18/2014 05:11 AM, Raphaël Jakse wrote: Peut-être qu'on devrait en discuter avec Ali et toi avant de faire quoi que ce soit. I uzoqeda lezo kamuva. Ali
Re: GPGPUs
On Friday, 16 August 2013 at 10:04:22 UTC, Russel Winder wrote: So the question I am interested in is whether D is the language that can allow me to express in a single codebase a program in which parts will be executed on one or more GPGPUs and parts on multiple CPUs. D has support for the latter, std.parallelism and std.concurrency. You can write everything in OpenCL and dispatch to both a CPU or GPU device, managing the submit queues yourself. I guess my question is whether people are interested in std.gpgpu (or some more sane name). What would be the purpose? To be on top of both CUDA and OpenCL?
