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 ?
