Re: Biology nerds needed in a D project!
On Thursday, 23 May 2019 at 23:17:08 UTC, Murilo wrote: Guys I'm trying to make a program that simulates a neuron which behaves like the Physarum polycephalum so it will be able to develop intelligence. I'm making it totally in the D programming language. I will need help from biology nerds. If you want to participate you can contact me: 1- on my GitHub: https://github.com/MuriloMir or 2- via e-mail: murilomirand...@hotmail.com or 3- via the Dlang facebook group: https://www.facebook.com/groups/662119670846705/ or 4- on my twitter: https://twitter.com/MuriloMN0 It doesn't matter how you model a neuron. Whatever sigmoid function you use will end up converging to the same result. All neurons function in the same way, and that is as a switch. This is why you can use all kinds of stuff for switches and it work. It seems that as long as they mimic a step function then it will work. I'd suggest you design your algorithms around using a generic neuron and then you can play around with specific implementations.
Re: Visual D 0.49.0 released
On Sunday, 7 April 2019 at 19:41:43 UTC, Rainer Schuetze wrote: Hello, the new release of Visual D has just been uploaded. Some major improvements of 0.49.0: * support for Visual Studio 2019 * parallel compilation supported by VC projects * catch up with recent language changes * new "Language" configuration page for -transition=/-preview=/-revert= options See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full list of changes. Visual D is a Visual Studio extension that adds D language support to VS2008-2019. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. The installer can be found at http://rainers.github.io/visuald/visuald/StartPage.html Rainer Thanks, do you know of any reason to upgrade to VS 2019? Does VD make any use of it?
Gillespie algorithm
Doing some physical simulations I could abstract the Gillespie algorithm, see https://code.dlang.org/packages/gillespied which may be useful. The number of algorithms able to model physical (continuous) time during an ongoing (reaction) process is rather limited. The announced algorithm is known to provide this feature. There are very much manifestations and improvements of the original Gillespie. In general, the improvements try to improve the speed of the algorithm either via - faster timing generation - faster next reaction look up - approximating the output by assumptions Compared to the standard Gillespie algorithm two enhancements were implemented: - for the case, reaction propensities are known, interarrival timings do not necessarily depend on a random number and its logarithm. This makes each time query faster. - If the governing simulation can handle non-nogc algorithm instantiation, a dedicated working array can be handled inside the algorithm. This provides faster next reaction search for all operations. All issues are of course welcome and will be tackled in my spare time. I hope, for this library, many further improvements, and applications could be found in future.
Re: a van Emde Boas tree
On Tuesday, 5 February 2019 at 16:04:03 UTC, Petar Kirov [ZombineDev] wrote: On Tuesday, 5 February 2019 at 15:47:30 UTC, Dejan Lekic wrote: On Tuesday, 5 February 2019 at 15:28:04 UTC, Alex wrote: Hi all, my van Emde Boas tree finally reached an announceable state, at version 0.12.0. vEB tree is an interesting data structure. Where is the implementation? - You did not provide any links... Most likely the repo is this one: https://github.com/Sandman83/vebtree Yes... sorry. Too deep in the code... https://code.dlang.org/packages/vebtree
a van Emde Boas tree
Hi all, my van Emde Boas tree finally reached an announceable state, at version 0.12.0. It operates on a closed universe, defined on construction. After that, the tree operates on unique key up to a certain capacity, which is at least as large as the universe size. All operations including insertion, removing, look up and next neighbor search are O(log(log(U)). min and max lookup are O(1). Some graphics are included on the front page for performance comparison with existent libraries. I relicensed the package to BSL-1.0 and moved it on github, so the documentation should work properly now. All tickets are welcome of course and will be managed in my spare time.
Re: We're looking for a Software Developer! (D language)
From my own experience, I strongly recommend that you check out these guys https://3atdev.com . They have rich experience building brands. So I'm 100% positive they'll develop a unique product that represents your brand in the best light.
Re: We're looking for a Software Developer! (D language)
If you are looking for a cost effective solution, you may want to consider outsourcing. This article may be pretty informative for you - https://diceus.com/why-you-should-open-outsourcing-centers-in-ukraine-nowadays/ . If there are some functions which your business cannot complete effectively and or professionally, you'll often save money and increase quality by outsourcing. Hope you find it useful!
Re: We're looking for a Software Developer! (D language)
hi there
Re: Meet our new scholarship recipient, Alexandru Jercaianu
On Monday, 2 October 2017 at 17:17:18 UTC, Suliman wrote: On Monday, 2 October 2017 at 17:04:30 UTC, Andrei Alexandrescu wrote: Hello everyone, it is my pleasure to announce that Alexandru Jercaianu, a starting MSc student at University "Politehnica" Bucharest, is recipient of our scholarship. Alex is up and running working on his bootcamp tasks. Currently he is attempting unsuccessfully to post in our general group :o). Please join me in welcoming Alexandru! Andrei Welcome Alexandru! Thanks! Looking forward to being part of the D community :) Alex
Re: A ready to use Vulkan triangle example for D
On Sunday, 29 May 2016 at 00:42:56 UTC, maik klein wrote:
On Sunday, 29 May 2016 at 00:37:54 UTC, Alex Parrill wrote:
On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote:
Btw does this even work? I think the struct initializers have
to be
Foo foo = { someVar: 1 };
`:` instead of a `=`
I didn't do this because I actually got autocompletion for
`vertexInputStateCreateInfo.` and that meant less typing for
me.
No, its equals. In C it's a colon, which is a tad confusing.
https://dpaste.dzfl.pl/bd29c970050a
Gah, I got them backwards. Colon in D, equals in C.
Could have sworn I checked before I posted that...
Re: A ready to use Vulkan triangle example for D
On Saturday, 28 May 2016 at 10:58:05 UTC, maik klein wrote:
derelict-vulcan only works on windows, dvulkan doesn't have the
platform dependend surface extensions for xlib, xcb, w32 and
wayland. Without them Vulkan is unusable for me.
I really don't care what I use, I just wanted something that
works.
Platform extension support will be in the next release of
d-vulkan. It doesn't include platform extensions now because I
wanted to find a way to implement it without tying d-vulkan to a
specific set of bindings, though I can't seem to find a good
solution unfortunately... I personally use the git version of
GLFW, which handles the platform-dependent surface handling for
me.
As for the demo itself... It might help explain things more if
the separate stages (instance creation, device creation, setting
up shaders, etc) were split into their own functions, instead of
stuffing everything into `main`.
Struct initializers are also useful when dealing with Vulkan info
structs, since you don't have to repeat the variable name each
time. Ex this:
VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo =
{};
vertexInputStateCreateInfo.sType =
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO;
vertexInputStateCreateInfo.vertexBindingDescriptionCount = 1;
vertexInputStateCreateInfo.pVertexBindingDescriptions =
vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1;
vertexInputStateCreateInfo.pVertexAttributeDescriptions =
Can become:
VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo =
{
sType =
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO, //
also sType is pre-set with erupted or d-derelict
vertexBindingDescriptionCount = 1,
pVertexBindingDescriptions = ,
vertexAttributeDescriptionCount = 1,
pVertexAttributeDescriptions = ,
};
Re: d-vulkan, automatically generated D bindings for Vulkan
On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: https://github.com/ColonelThirtyTwo/dvulkan I've updated the bindings to Vulkan 1.0.13, and added a few fixes. Platform support will come in a bit. I'm going to use void* pointers for most of the platform-specific types, so you can use whatever bindings you want to use with them (whether they are full bindings or just one little opaque struct alias to use with, say, glfw).
Re: [Blog post] Why and when you should use SoA
On Sunday, 27 March 2016 at 00:42:07 UTC, maik klein wrote: I think SoA can be faster if you are commonly iterating over a section of a dataset, but I don't think that's a common occurrence. This happens in games very often when you use inheritance, your objects just will grow really big the more functionality you add. Like for example you just want to move all objects based on velocity, so you just care about Position, Velocity. You don't have to load anything else into memory. An entity component system really is just SoA at its core. You can't have a struct-of-arrays with polymorphic data like game objects; the individual objects would have different properties and methods. If you use a Unity-esque component system, you could potentially pool each object's component into an array... but then whatever component updates you're running likely touch most of the object state anyway (ex. the hypothetical PositionComponent would be updating both its position and velocity). Also I forgot to mention: Your "Isn’t SoA premature optimization?" section is a textbook YAGNI violation. I might have to refactor my web app to support running across multiple servers and internationalization when it becomes the Next Big Thing, but it more than likely will not become the Next Big Thing, so it's not productive for me to add additional complexity to "make sure my code scales" (and yes, SoA does add complexity, even if you hide it with templates and methods). Since AoS vs SoA is highly dependent on usage, I'd like to see some performance metrics with real-world access patterns instead of benchmarks that unrealistically only look at part of the data at a time, or use structs that are too small to matter. Of course, actually getting those metrics is the hard part...
Re: [Blog post] Why and when you should use SoA
On Friday, 25 March 2016 at 01:07:16 UTC, maik klein wrote: Link to the blog post: https://maikklein.github.io/post/soa-d/ Link to the reddit discussion: https://www.reddit.com/r/programming/comments/4buivf/why_and_when_you_should_use_soa/ I think structs-of-arrays are a lot more situational than you make them out to be. You say, at the end of your article, that "SoA scales much better because you can partially access your data without needlessly loading unrelevant data into your cache". But most of the time, programs access struct fields close together in time (i.e. accessing one field of a struct usually means that you will access another field shortly). In that case, you've now split your data across multiple cache lines; not good. Your ENetPeer example works against you here; the the packetThrottle* variables would be split up into different arrays, but they will likely be checked together when throttling packets. Though admittedly, it's easy to fix; put fields likely to be accessed together in their own struct. The SoA approach also makes random access more inefficient and makes it harder for objects to have identity. Again, your ENetPeer example works against you; it's common for servers to need to send packets to individual clients rather than broadcasting them. With the SoA approach, you end up accessing a tiny part of multiple arrays, and load several cache lines containing data for ENetPeers that you don't care about (i.e. loading irrelevant data). I think SoA can be faster if you are commonly iterating over a section of a dataset, but I don't think that's a common occurrence. I definitely think it's unwarranted to conclude that SoAs "scale much better" without noting when they scale better, especially without benchmarks. I will admit, though, that the template for making the struct-of-arrays is a nice demonstration of D's templates.
d-vulkan, automatically generated D bindings for Vulkan
https://github.com/ColonelThirtyTwo/dvulkan I know there are a few other bindings for Vulkan around, but I didn't see one that generated the bindings from the XML spec, so I made d-vulkan. The included vkdgen.py script leverages the spec parser included in the Vulkan-Docs repo to generate D bindings that can easily be updated with new versions and extensions. The bindings load all functions using the vkGetInstanceProcAddr function; however, it does not provide any way of loading that function by default, and you must provide it when loading Vulkan. The `with-derelict-loader` dub configuration provides uses derelict.util to load the vkGetInstanceProcAddr function, and I've added a wiki page demonstrating loading the function using GLFW. This includes bindings for all extensions, except for the platform-dependent VK_KHR_*_surface APIs, which require type declarations from other projects (like X11) that I didn't want to include. The platform-independent VK_KHR_surface extension is available, however. (Currently the Derelict loader only works in Windows because I don't know the library names for Vulkan on Linux or OSX; if anyone knows them, please tell me, and I'll add them)
Re: d-vulkan, automatically generated D bindings for Vulkan
On Sunday, 20 March 2016 at 00:03:16 UTC, Nicholas Wilson wrote:
On Saturday, 19 March 2016 at 19:37:38 UTC, Alex Parrill wrote:
On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson
wrote:
On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill
wrote:
Should be doable using appropriate version blocks.
The problem is that I'd have to define my own structs (Xlib
Display, Xlib Window, etc), which will be incompatible with
the ones defined in any bindings to those libraries.
You don't. Code in undefined versions need only be
syntactically valid
not semantically valid. i.e. the types in versions not compiled
in need not
be declared nor defined.
version(none)
{
xcb_connection_t* con;
}
will compile fine.
Yes, I know. The issue is, when compiling with the version, where
does xcb_connection_t come from? If I declare it myself, as
`struct xcb_connection_t;` in the version block, then that type
will be different than the xcb_connection_t declared in the XCB
bindings that the developer is likely using, and thus they will
be incompatible. If I import a xcb_connection_t from some
bindings, it ties d-vulkan to those bindings, which I'd rather
not do.
Re: d-vulkan, automatically generated D bindings for Vulkan
On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote: On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: Should be doable using appropriate version blocks. The problem is that I'd have to define my own structs (Xlib Display, Xlib Window, etc), which will be incompatible with the ones defined in any bindings to those libraries.
Utah Meetup group
Hello D programmers, I'm trying to get a Utah D meetup started, if you're interested, let me know here ( https://docs.google.com/forms/d/13Y8S0aBntCiEGxiCXyCrPwjdG1h3zRXOxCpyzN95U6s/viewform ), and I'll email everyone who replied in a week or so about the numbers, and the next step if there's a good amount of demand. Thanks, Alex
Re: Voting for std.experimental.allocator
On Friday, 10 July 2015 at 18:32:04 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei It leaks. http://forum.dlang.org/post/itmcarskypkuospvf...@forum.dlang.org
Re: Voting for std.experimental.allocator
Yes, but the mmap allocator on Windows needs to be fixed.
Re: Travis-CI support for D
On Tuesday, 2 June 2015 at 18:54:14 UTC, Atila Neves wrote: It doesn't seem to work anymore, even http://lint.travis-ci.org/ says I can't use language: d. Atila Works for me, though the linter doesn't know about it.
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Friday, 5 September 2014 at 12:15:09 UTC, Bruno Medeiros wrote: On 05/09/2014 07:32, Jacob Carlborg wrote: Perhaps I'm nitpicking but an external tools doesn't sound like a good idea. A completely separate library that can be shared among tools and be integrated into an IDE, absolutely yes. But not a tool. It's like it was said earlier, a library is easier to integrate, but only if across the same language (for the code the library is written in, and the code the IDE extensions are written in). Well, I spent a (very little though) time getting informed on how everything could be done using dcd-server running in the background. 1) the communication between dcd-server and dcd-client happens via tcp ipc. So extremely easy to implement 2) The currently edited module's text can be piped through that IPC channel to not have to query the hardware IO all the time. 3) My completion 'model' allows having individual import paths for each edited file, project, super-project aka solution. DCD seems not to support this atm(?). 4) D_Parser is heavily woven with all kinds of Mono-D features, so just ripping out the completion component and replacing it with dcd won't bring anything sustainable, since I'd still had to have raw access to all ASTs out there in order to e.g. display a 'breadcrumb' path bar on the editor's top, the doc outline, refactoring features etc. -- An entirely separate Mono-D is needed imho which probably only features basic projecting/build support as well as dcd bindings. Did you, Bruno, discarded your customly written completion framework in favor of dcd?
Re: LDC 0.14.0 released!
On Wednesday, 20 August 2014 at 04:48:02 UTC, Kai Nacke wrote: On Friday, 15 August 2014 at 15:04:44 UTC, Kai Nacke wrote: Hi everyone, LDC 0.14.0, the LLVM-based D compiler, is available for download! This release is based on the 2.065.0 frontend and standard library and supports LLVM 3.1-3.4.2 (OS X: 3.2/3.4 only). As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/ynlnfdqwkweenkwct...@forum.dlang.org Regards, Kai I managed to get mentioned in LLVM Weekly again. (http://llvmweekly.org/issue/33) LLVM weekly is a newsletter with high attention in the LLVM world. Regards, Kai Nice :)
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Thursday, 14 August 2014 at 00:54:07 UTC, Brian Schott wrote: On Thursday, 14 August 2014 at 00:43:38 UTC, Damian Day wrote: I'm not sure you'd want to do that. The DParser completion engine has a few features that DCD doesn't have. (I'm not sure if this is true the other way around) That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer. Keep in mind that integrating a lexer/parser written in C# into an IDE written in C# is much easier than integrating libdparse would be. The same argument applies to Eclipse and Visual Studio. Invoking stuff is easy. I'd rather reimplement the communication to the dcd server instead to not get such a bottleneck if you're on windows or typing really fast. Executing an entire program for each keystroke is a real unsustainable solution, imho. I'm particularly interested in dscanner integration myself :) Are you talking about displaying static analysis hints in the editor window, or something else? Yes precisely. This should be easy. I have Textadept set up to do this and the implementation is only a few lines long. https://github.com/Hackerpilot/TextadeptModules/blob/master/modules/dmd/init.lua#L29-54 This seems rather easy to implement.
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote: Invoking stuff is easy. I'd rather reimplement the communication to the dcd server instead to not get such a bottleneck if you're on windows or typing really fast. Executing an entire program for each keystroke is a real unsustainable solution, imho. https://github.com/Hackerpilot/DCD/blob/master/client.d#L72 Alright. :-)
[Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
Hey everyone, it's been quite some while ago that I posted a Mono-D release announcement on to D.announce :) You should've noticed that the installation instruction stuff has been moved to the D wiki - http://wiki.dlang.org/Mono-D There have been several fixes and smaller improvements since the last bunch of bug fix releases. Detailed release notes can be taken from the wiki entry. Cheers, Alex
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Wednesday, 13 August 2014 at 14:23:47 UTC, Théo Bueno wrote: On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote: Hey everyone, it's been quite some while ago that I posted a Mono-D release announcement on to D.announce :) You should've noticed that the installation instruction stuff has been moved to the D wiki - http://wiki.dlang.org/Mono-D There have been several fixes and smaller improvements since the last bunch of bug fix releases. Detailed release notes can be taken from the wiki entry. Cheers, Alex We definetely should promote Mono-D along with Visual D, and move your documentation stuff from the wiki to the website. Again, thank you for your awesome work :) Only if I have wiki-like online editing available then :P -- I don't want to mess with hardcore html anymore :-/
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On Wednesday, 13 August 2014 at 20:47:41 UTC, simendsjo wrote: Not for me. Doesn't work in firefox either (and I'm pretty sure I haven't visited the wiki ever with firefox). /me leans back and enjoys the OT Still not working for me either. But no problem, it's the text and the images that count :-P
Re: DConf 2013 Day 3 Talk 4: LDC by David Nadlinger
Great talk! Regarding the ci.lycus.org fleet, credit should definitely go to Adam Wilson (C# to D talk) and Kelly Wilson (same person who was present in the pie chart) too for providing many of the machines hooked up to the master node. The fleet doesn't do a whole lot of work most of the time, so if you have a project that 1) has a sane build system; 2) you're willing to respond to build failures on; 3) and is 'significant' enough, feel free to email me and I'll see what I can do. (By 'significant' I mean has enough impact to be useful for a reasonable amount of D programmers. This is of course pretty subjective, but we have to be a bit conservative about how many projects we add so that we don't end up having lots of stalled builds in the queue.)
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On Friday, 17 May 2013 at 17:39:42 UTC, Rainer Schuetze wrote: On 15.05.2013 23:19, alex wrote: On Saturday, 11 May 2013 at 10:39:39 UTC, Rainer Schuetze wrote: Hi, a new version of Visual D is long overdue, so finally it is released. In addition to the usual fixes of bugs and regressions, the major highlights of this version are - DParser by Alexander Bothe (https://github.com/aBothe/D_Parser, also used by Mono-D) integrated as an alternative semantic engine for better code completion (use Open Language options from the Visual D menu to access the enable option) Finally :) -- Hopefully I can find some more time to do more pre-compile time analysis implementation of D code ;) Oh btw, have you implemented the D_Parser.Misc.CompletionOptions? You can toggle mixin pre-evaluation and other tweaks over there I just left them at their default, i.e. UFCS is enabled, but mixin-support is disabled. Any problem with enabling the latter? The other options seem unused sofar when grepping for them, maybe they are used by Mono-D, but not DParser (the version used by the installer doesn't have the HideDeprecatedNodes option). mixin support might be good (but well, it's still and probably will ever be basic) -- there are problems with having too many mixins in one module, that's why I left it opt-in only. Anyway the option might be nice to have somewhere :)
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On Saturday, 11 May 2013 at 10:39:39 UTC, Rainer Schuetze wrote: Hi, a new version of Visual D is long overdue, so finally it is released. In addition to the usual fixes of bugs and regressions, the major highlights of this version are - DParser by Alexander Bothe (https://github.com/aBothe/D_Parser, also used by Mono-D) integrated as an alternative semantic engine for better code completion (use Open Language options from the Visual D menu to access the enable option) Finally :) -- Hopefully I can find some more time to do more pre-compile time analysis implementation of D code ;) Oh btw, have you implemented the D_Parser.Misc.CompletionOptions? You can toggle mixin pre-evaluation and other tweaks over there
Re: DUB 0.9.13 released
On Tuesday, 16 April 2013 at 21:50:10 UTC, Sönke Ludwig wrote: Changes: - Support for a new buildRequirements field to be able to specify things like Don't treat warnings as errors or Allow use of deprecated features - A lot of improvements to the VisualD project generator - Some important bug fixes Change log: https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md Download: http://registry.vibed.org/download I want to inform you that Mono-D v0.5.2.4 can open Dub projects natively now - no need for creating .dproj files explicitly anymore, just opening package.json is required in order to have the project there. It also handles include paths in the most common cases. Btw, what about nested dependencies? How are they handled in dub? Are all sub-packages in the .dub folder read for further dependency information? Great work though!
Re: DUB 0.9.13 released
On Friday, 26 April 2013 at 20:16:15 UTC, Sönke Ludwig wrote: Am 26.04.2013 21:37, schrieb alex: I want to inform you that Mono-D v0.5.2.4 can open Dub projects natively now - no need for creating .dproj files explicitly anymore, just opening package.json is required in order to have the project there. It also handles include paths in the most common cases. Cool! I'll try that out tomorrow. Do you execute the dub binary to generate a project file or do you parse the package.json directly? If it helps, it would be relatively easy to add a mode where all build settings for the project, including all of its dependencies, are output to stdout as JSON. It parses the package.json directly, no .sln or .dproj is generated. It runs dub build for building and dub for executing the program -- where do I specify run arguments btw? Btw, what about nested dependencies? How are they handled in dub? Are all sub-packages in the .dub folder read for further dependency information? Yes, the ones in .dub, in the system- and user-wide package folders, as well as any package added with dub add-local are scanned for where is the list of packages added with 'add-local' stored at? matches recursively and their build settings are merged-in accordingly. I think I might open up all the dependency projects as well when opening the 'root' package.json - do you think that it's a good idea or just distracting the user from the main project? Great work though! Thanks, the same must be said about Mono-D! (which is a lot more complex, of course) :-)
Re: DUB 0.9.13 released
On Friday, 26 April 2013 at 20:47:42 UTC, Rory McGuire wrote: I'd say opening all dependencies is distracting. But being able to open them quickly is really useful. I think I should create greyed-out references in the pseudo-solution which can be enabled and loaded afterwards if wanted. Or so..
Mono-D v0.5.1.5 - Bug fixes
Hi everyone, Just wanted to announce a further bug fix release. Nothing *so* important except that it now alters the AST e.g. when you're at the end of a method body and pressing Return, it'll increase the body's endlocation which lets the completion work fine until the complete file gets reparsed after half a second. Enjoy it keep filing issue reports! :) http://mono-d.alexanderbothe.com/?p=912 https://github.com/aBothe/Mono-D/issues
Re: Mono-D v0.5.1.4 - Bugs 'n' Improvements
On Friday, 15 March 2013 at 21:07:07 UTC, notna wrote: This website is a mess. The home still shows v3, following the download, you'll reach v4.0 (windows)... which is so ugly and buggy. The latest for windows, which I found in their forum, is: http://download.xamarin.com/studio/Windows/XamarinStudio-4.0.1.msi They just don't care about distribution on Linux anymore - there is a variety of reasons for this, but anyway I loaded up a custom bundle so you aren't forced to use their website (anymore) ;)
Re: Mono-D v0.5.1.4 - Bugs 'n' Improvements
On Friday, 15 March 2013 at 00:50:57 UTC, Nick Sabalausky wrote: On Thu, 14 Mar 2013 23:42:04 +0100 alex i...@alexanderbothe.com wrote: On Thursday, 14 March 2013 at 22:33:38 UTC, Nick Sabalausky wrote: On Thu, 14 Mar 2013 22:46:43 +0100 alex i...@alexanderbothe.com wrote: Nope. You can switch it so some darker schemes. I also switched it to some darker background because it also was too bright for me. I couldn't find any settings for that. Where are they? On Windows, it's Tools - Options - Text Editor - Syntax highlighting. Just select an other scheme, close the options dlg and you'll see it :) That's only affecting the text editor, not the rest of the UI. Ironically, the text editor is one thing that does display just fine with the default settings (aside from being very bright). Oh noooees. Seriously, the only bright things in the main UI are only a menu bar and the solution pad, by default - Imho a circumstance which one can survive easily ;-D
Re: Mono-D v0.5.1.4 - Bugs 'n' Improvements
On Friday, 15 March 2013 at 14:33:06 UTC, Nick Sabalausky wrote: Even ignoring the disregard my system settings overdose of white, the UI is still just generally very difficult to read due to what appears to be a (more or less) buggy theme. Note in particular: 1. Invisible menu items. 2. Very-light-grey on white menu items. 3. Generally messed up text on buttons. 4. Overzealous anti-aliasing on the dialog text such as C:\Users... and Always create a backup copy. Not as bad as the first three, but it'll still hurt a guy's eyes after a while. http://i.imgur.com/nZxJIgO.png Can't see a problem on my side, literally.
Re: Mono-D v0.5.1.4 - Bugs 'n' Improvements
On Thursday, 14 March 2013 at 20:47:57 UTC, Andrej Mitrovic wrote: On 3/14/13, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: Wikipedia's MonoDevelop page says Xamarin offers a rebranded version of MonoDevlop 4.0 as Xamarin Studio which now uses platform-specific code in various places to enhance the look feel. So sounds good :) Unfortunately they now forcefully bundle the Android SDK, which I have no use for, but have to wait downloading 800MB.. 800 Megs? My download was only 31 MB large ;) Please consider downloading the version from http://monodevelop.com/download -- you don't have to register to the Xamarin site then.
Re: Mono-D v0.5.1.4 - Bugs 'n' Improvements
On Thursday, 14 March 2013 at 21:25:44 UTC, Nick Sabalausky wrote: On Thu, 14 Mar 2013 21:47:43 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 3/14/13, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: Wikipedia's MonoDevelop page says Xamarin offers a rebranded version of MonoDevlop 4.0 as Xamarin Studio which now uses platform-specific code in various places to enhance the look feel. So sounds good :) Unfortunately they now forcefully bundle the Android SDK, which I have no use for, but have to wait downloading 800MB.. It didn't do that for me. *shrug* Unfortunately, Xamarin tries to force its own color scheme, and only partially succeeds at it, leaving the program filled with barely-readable light-on-light text and other text that appears partially-rendered kinda like anti-aliasing gone terribly wrong (not to mention lots of eye-searing plain-white backgrounds). I'm not a GTK fan, but when I get a chance I'll have to try compiling the plain-vanilla non-Xamarin MonoDevelop if there indeed isn't a pre-built Windows version of it. Nope. You can switch it so some darker schemes. I also switched it to some darker background because it also was too bright for me.
Re: Mono-D v0.5.1.4 - Bugs 'n' Improvements
On Thursday, 14 March 2013 at 22:33:38 UTC, Nick Sabalausky wrote: On Thu, 14 Mar 2013 22:46:43 +0100 alex i...@alexanderbothe.com wrote: Nope. You can switch it so some darker schemes. I also switched it to some darker background because it also was too bright for me. I couldn't find any settings for that. Where are they? On Windows, it's Tools - Options - Text Editor - Syntax highlighting. Just select an other scheme, close the options dlg and you'll see it :)
Re: Unmanaged - a D framework on github
On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote: Hello, I'd like to introduce the Unmanaged framework. It's a OOP library, strongly inspired by the Delphi/Pascal RTL. Its main concept is to bypass the GC. From this statement, the library feaures: - main unmanaged object and memory routines - a parameterized list - an ownership system (used to automate the destroying of object) - a parentship system - a serialization system... - etc work in progress. This library is developped in the same time I learn D, but comming from Delphi, it's inspired by its class system (but it's not a copy at all). Unmanaged is tested under win32 an linux64. Basic build scripts are provided for both systems and code review are welcome. you can track the project on github: https://github.com/BBasile/Unmanaged Hey. Pascal case identifiers 3 - Looks great!
Mono-D v0.5.1.4 - Bugs 'n' Improvements
Hi everyone, I've recently finished a couple of bug fixes and smaller improvements which should make Mono-D an even better IDE. And please, if you experience (and I'm sure you will) bugs or smaller (not only, but preferably completion) annoyances, do spam the issue board or the blog with bug fix requests! - If there's a library construct that's not supported yet, please report it, because I don't really have the time to find out stuff and my coding in D mostly happens w/o huge template constructs. http://mono-d.alexanderbothe.com/?p=909 https://github.com/aBothe/Mono-D/issues
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On Monday, 25 February 2013 at 08:22:04 UTC, Sönke Ludwig wrote: Looking good! But funny to see how Xamarin now also thinks that iTunes is a good role model for an IDE :D But well, it works and looks clean here, I just found it funny when XCode did the same thing back then. Well, I like the new design - mainly because the entire tool bar trash disappeared and the editor/completion stuff has been improved a lot :) I now get an error from dmd that a filename or extension is too long (I *think* it worked with MD 3.5 and the previous Mono-D). Passing the same command line that is printed in the build output window as a @responsefile to dmd works, but putting it directly as a command line is too long for cmd.exe to handle. I couldn't get the original error message to reproduce, though. I'll file a bug report later, need to make a repo case. Original error message: Erstellen fehlgeschlagen. Der Dateiname oder die Erweiterung ist zu lang I had this error too - but not in Mono-D/Xamarin Studio, just when actually trying to build my relatively small self-built framework via console.. currently dunno how to handle this
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On Monday, 25 February 2013 at 08:54:00 UTC, Jacob Carlborg wrote: Did you happened to find that deadlock issue? Which one? I've fixed a such an issue a month ago - the one I wrote about in the blog post isn't a deadlock, it's just an infinite loop..hopefully I'll get another chance to reproduce it
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On Monday, 25 February 2013 at 15:13:29 UTC, Jacob Carlborg wrote: On 2013-02-25 15:42, alex wrote: Which one? I was referring to this post: http://forum.dlang.org/thread/tdmiqlxzbroktmcrv...@forum.dlang.org#post-rdzfcgypxusahrhwelcu:40forum.dlang.org Yep, that's the one I fixed recently.
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On Monday, 25 February 2013 at 15:51:14 UTC, Jacob Carlborg wrote: On 2013-02-25 16:25, alex wrote: Yep, that's the one I fixed recently. Aha, cool. I'll have to give it a try. BTW, is the Xamarin Studio IDE free? Yes. And I hope it'll remain free :)
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On Monday, 25 February 2013 at 22:02:13 UTC, F i L wrote: alex wrote: Do you know a relatively consistent way of building MD 4.0 from scratch and having it 'installed' on one's machine, so with a launcher on the desktop? I don't know, but MonoDevelop 4.0 was just on the Arch Repos yesterday :) Gotta hand it to the MD devs, they really did an excellent job with MD 4.0 The UI is slick and straight-forward The C# code-completion is much better The new Sublime-inspired colors are completely sexy And overall, the performance feels improved in every way. Mono-D is running good so far! Thanks for your work. Yep, I'm also glad it's gotten a new UI that feels more modern. Can't even await the first bug fix release that shall come up in a couple of days :)
Re: Mono-D v0.4.9.9 Bug fixes
On Monday, 11 February 2013 at 09:07:59 UTC, Johannes Pfau wrote: Am Mon, 11 Feb 2013 03:25:25 +0100 schrieb alex i...@alexanderbothe.com: Hi everyone, Just released another bunch of bug fixes solved issues http://mono-d.alexanderbothe.com/?p=840 May I ask you how long you have to wait for phobos stuff to pop up in the completion list after you launched Mono-D? I've just installed a non-virtual Mint and had to experience wait very long until stuff like std showed up.. but here on my Windows machine, it just takes ~3 seconds to parse everything + UFCS preparation, so at least as half as long as it takes on the Linux installation..wth? ~20 seconds here on fedora 17 with ufcs. I just found out: It's not the parser, it's probably a deadlock - though I don't know why it's actually working under .Net then.. But okay, I've got a trace, I'll try to fix it - and I've got a 0.5 version then.
Mono-D v0.4.9.9 Bug fixes
Hi everyone, Just released another bunch of bug fixes solved issues http://mono-d.alexanderbothe.com/?p=840 May I ask you how long you have to wait for phobos stuff to pop up in the completion list after you launched Mono-D? I've just installed a non-virtual Mint and had to experience wait very long until stuff like std showed up.. but here on my Windows machine, it just takes ~3 seconds to parse everything + UFCS preparation, so at least as half as long as it takes on the Linux installation..wth? I've compiled all the stuff manually to check where some fundamental reasons are located for this - it ran faster (but still not fast enough) after I disabled multi-threading! Whereas on Windows, I actually established a multi-threaded environment for all the analysis tasks!? -- Mad stuff. What's really interesting is that it takes about 170-200 ms to parse std.datetime on both platforms - so not really different at all. Again, mad stuff. Anyway I've always thought everything would be fine with the analysis performance - even on my small Netbook rig from 2011 that is driven by a tiny 1.66 GHz Atom CPU with Win7 on it only takes 5 seconds for everything - even less than Mono takes for parsing phobos with 2(!) threads.. Still troubleshooting so far.. Oh, and please keep reporting issues - just raging silently and immediately uninstalling the addin isn't making it better at all! https://github.com/aBothe/Mono-D/issues
Re: Mono-D v0.4.9.9 Bug fixes
On Monday, 11 February 2013 at 03:18:41 UTC, F i L wrote: Yeah it takes probably 20-40 seconds on my Phenom II X4 920 (Arch Linux 64). Haven't MonoD on Windows (or Mac) in awhile, so I haven't noticed any difference. I think MonoDevelop on Windows actually uses MS .NET (not Mono).. could be wrong about that, but if it's true, that could be the reason for the slow down (Mono is much slower than MS .Net). Thanks for the update! I've got to step deeper into this, I guess. Parsing phobos druntime ufcs args in MonoDevelop took 1.8 seconds, a last test in D-IDE resulted in 1.7 seconds..awkwardly strange!
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Wednesday, 30 January 2013 at 10:45:26 UTC, Jacob Carlborg wrote: On 2013-01-30 00:28, alex wrote: Okay, I've uploaded a new version that features a basically working version. There is now a separated mixin insight and expression evaluation available. There are still many things left to do though. I'll give it a try. I'm currently too tired to start a new thread for announcing another bug fix release: http://mono-d.alexanderbothe.com/?p=825
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Tuesday, 29 January 2013 at 09:42:49 UTC, Timon Gehr wrote: On 01/29/2013 03:14 AM, alex wrote: On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote: ... http://mono-d.alexanderbothe.com/?attachment_id=817 My progress so far. Lots of internals to manage though. The execute-button isn't implemented yet but you can toggle the Automatically take the mixin at the caret location button. Concerning things like foo(1,2) - yes, the evaluation engine directly takes the symbols straight out of its parsed modules. So as you create a method body you'll be able to execute stuff in-line. But yeah, remember that CTFE isn't implemented yet ;) - Perhaps I'll do/finish it during the next GSoC. ... Probably you should do JIT using System.Reflection.Emit. Why not write an entire D# compiler? ;) (jk, I originally planned to do this right after I've finished mono-d :D)
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Tuesday, 29 January 2013 at 08:02:27 UTC, Jacob Carlborg wrote: ... Yeah, that was s cool. I also liked the code bubbles. Instead of having a file as the minimum abstraction unit in the IDE/editor it was a function/class/method. Which can be done in Eclipse by just selecting e.g. a method or class in the outline - iirc it'll just show the definition of the selected node then, nothing else.
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Sunday, 27 January 2013 at 15:24:23 UTC, Jacob Carlborg wrote: On 2013-01-27 13:35, alex wrote: Well, not displaying the entire module but only displaying resolved expressions. Dunno how to do this in a proper way - only via tooltips or also in an extra panel? Which would be the most useful? If it cannot show the entire module then I think a tooltip would be best suited. Btw, since I'm not that involved in D's magic I definitely haven't planned such extensive pre-compilation :D It can be extremely helpful to see how a template/string mixin is expanded when debugging. It can also be fun to see how the compiler behaves internally, i.e. scope-statements are lowered to try/catch/finally. Any D IDE has quite a lot of expectations to live up since it most certainly will be compared with Descent. K..Created an extra panel, and the actual mixin evaluation is working, too. But now there are some last adjustments required to have the entire mechanism as few annoying and performance-reducing as possible.
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Sunday, 27 January 2013 at 23:14:23 UTC, F i L wrote: alex wrote: Morning D folks, Implemented some new features concerning pre-compile time mixin analysis and expression evaluation: ... The new update seems very fast and stable. Trying the new features, Thanks! And if not, you know the routine :)
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Monday, 28 January 2013 at 20:20:42 UTC, Jacob Carlborg wrote: On 2013-01-28 13:32, alex wrote: K..Created an extra panel, and the actual mixin evaluation is working, too. But now there are some last adjustments required to have the entire mechanism as few annoying and performance-reducing as possible. Cool, I guess it's time to give Mono-D another try. http://i.imgur.com/3i5R4Mn.png?1 A first shot - I guess in cases of having template parameters, stuff should get 'expanded' to the final type, right? Well then I still have to work on it. Anyway it also works for template mixins and mixin statements. You just move the caret into a mixin, wait half a sec and then get the evaluated string displayed in a halfway good style. Ah, regarding the style..I also have to optimize it again - never touched any 'pretty printing' of entire ASTs before ;)
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Monday, 28 January 2013 at 21:14:07 UTC, F i L wrote: alex wrote: http://i.imgur.com/3i5R4Mn.png?1 A first shot - I guess in cases of having template parameters, stuff should get 'expanded' to the final type, right? Well then I still have to work on it. Anyway it also works for template mixins and mixin statements. You just move the caret into a mixin, wait half a sec and then get the evaluated string displayed in a halfway good style. Ah, regarding the style..I also have to optimize it again - never touched any 'pretty printing' of entire ASTs before ;) Now that's impressive. Can't wait to see exactly what will come of the expression evaluation :D Yeah I just named it Expression evaluation - dunno why, just thought that it could be used in a more general way than 'only' for mixin insight. Should I do an extra input box where you could type in expressions and other things that could be evaluated? Just thinking of a prototype of an interactive D script console or so.. :)
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
...
That sounds very useful. It would be awesome if you could
evaluate the returned value of functions that already exist in
your program, or (like your picture shows) write simple test
functions to evaluate. Of course not all functions will work,
but It would be great in some areas. So, just to be clear, say
you have the following function in your project:
int foo(int x, int y)
{
return x * y + 5;
}
Then in the expression command line, you just type:
foo(1, 2)
Hit Enter, and you get a message: 7. You could also write
larger test functions in the Expression Evaluation body (like
in your screenshot) which could do more complicated stuff
(still limited of course).
http://mono-d.alexanderbothe.com/?attachment_id=817
My progress so far. Lots of internals to manage though. The
execute-button isn't implemented yet but you can toggle the
Automatically take the mixin at the caret location button.
Concerning things like foo(1,2) - yes, the evaluation engine
directly takes the symbols straight out of its parsed modules. So
as you create a method body you'll be able to execute stuff
in-line. But yeah, remember that CTFE isn't implemented yet ;) -
Perhaps I'll do/finish it during the next GSoC.
Haha, as a systematical performance pre-improvement I could
directly redirect some phobos methods like sqrt() to the .net one
- which would save huge amounts of time then.
You just gave me an awesome idea though. I know this would be a
ton of work (I'm not making a feature request here), but how
realistic would it be with your system to do a side-by-side
expression evaluation with example data (where applicable)? :D
Meaning, imagine your screen looks like:
CODE | EXAMPLE RESULTS
|
int foo(int x, int y) | params: (2, 3) // editable
{ |
return x * y + 5 | returns: 11// not-editable
} |
|
That would simply amazing! I don't expect you to make that,
lol, only want to know if it's possible (or foreseeable) with
your expression evaluation engine. Is it?
Side-by-side? This could be your contribution then :P
I actually did watch this one video where that one guy just
edited some javascript in his uber-editor and the WebGL
animations reacted on his coding in pseudo-realtime in the
browser :D
Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
Morning D folks, Implemented some new features concerning pre-compile time mixin analysis and expression evaluation: http://mono-d.alexanderbothe.com/?p=814 (Screenshot included) I'd furthermore suggest that the prospective generational GC (not the current one, I mean the fictional that actually can collect nearly everything wisely! ;)) also supports weak references - because they're imho essential for a nice caching flow: In this version of mono-d I used a weak-keyed dictionary to store mixin expression results until the owner module is free'd and probably reparsed. This allows me to be more lazy regarding the deletion of those cache entries after I reparsed e.g. a module + mem leaking is prevented + less muddy code in the module update routines! :) Cheers, Alex
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On Sunday, 27 January 2013 at 11:31:58 UTC, Dicebot wrote: Gets better and better! Makes me wonder though: if this works, may be it is possible to provide a context helper with mixin resulting code if all it parameters are already defined? Similar to C macro expansion helper in Eclipse. So like.. you click somewhere in your document, have an extra panel in which you can enter an expression (even a CTFE call later on), and get your expressions evaluated? Sure - even stuff like template mixins or similar..no problem :) Uhm, even pre-defining variable contents shouldn't be a problem - then you would have a D math-script interpreter :D
Re: Mono-D v0.4.9 - Rough formatting capability
On Saturday, 26 January 2013 at 08:22:39 UTC, Rainer Schuetze wrote: On 25.01.2013 21:34, Jacob Carlborg wrote: On 2013-01-25 20:00, alex wrote: I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :) It should provide an C interface, then it can be connected to anything. COM is the natural choice when interfacing native code on Windows with C#. On other platforms it might be different. The semantic engine in Visual D is separated into another process and communicates with the IDE plugin through a number of commands, just using this interface: https://github.com/rainers/visuald/blob/master/vdc/ivdserver.d . This can easily be mapped to C calls. There's also an implementation of that interface using D_Parser (https://github.com/rainers/visuald/tree/master/vdc/abothe), but it isn't complete yet. Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then!
Re: Mono-D v0.4.9 - Rough formatting capability
On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote: Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then! Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea?
Re: Mono-D v0.4.9 - Rough formatting capability
On Saturday, 26 January 2013 at 12:28:11 UTC, Rainer Schuetze wrote: On 26.01.2013 13:09, alex wrote: On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote: Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then! Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea? That's actually what the Visual D semantic server process does. Lol. Syntax highlighting and indenting are done in the plugin, though. These don't need anything more than lexing so far and must be fast. Isn't there any integrated lexing done by the VS editor component? MD as well as #develop provide simple syntax definitions. But well, semantic type highlighting..yeah, this could be an issue - whereas..this process takes only 1 ms or so in D-IDE, so this shouldn't be a problem. Specifying import paths and compile options isn't so easy, because you can have different options for different projects in the solution, meaning the same file might be even used with different settings. That's also one of the points where integration of D_Parser is kind of brittle. This wouldn't be a problem: There already is a strict separation of global (phobos, tango, vibe.d) and local (project, project-specific include) module sets in the parse cache. As I already said, changes to single documents could be passed to a document 'mirror' in the completion server immediately. Wait, the same file might be used with different settings? Hehe, there actually are no settings for parsing and code completion. Anyway, why should two projects make use of two files? Even if, this wouldn't be any reason to turn mad - the AST was just stored in two parse caches then, so no problem at all :)
Re: Mono-D v0.4.9 - Rough formatting capability
On Friday, 25 January 2013 at 13:43:46 UTC, Jacob Carlborg wrote: I didn't say anything about porting :) I was suggesting you integrate the VisualD parser without porting it. That's why I suggested the one in VisualD and not the one in Mono-D. I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :)
Re: Mono-D v0.4.9 - Rough formatting capability
On Friday, 25 January 2013 at 20:34:28 UTC, Jacob Carlborg wrote: On 2013-01-25 20:00, alex wrote: I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :) It should provide an C interface, then it can be connected to anything. Why not wrap dmd's front-end?
Re: Mono-D v0.4.9 - Rough formatting capability
On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote: On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote: On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :) Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this! Uhm..what is an auto-formatter in your eyes? Automatic formatting when you typed a '}' for instance? Or just the explicit possibility to let a program format your code? I mean, once the code got indented correctly, why should it ever be passed through a formatter again? Just to see that it's actually been indented correctly? Hmm..
Re: Mono-D v0.4.9 - Rough formatting capability
On Tuesday, 22 January 2013 at 15:54:46 UTC, mist wrote: I always define project code style policies in Eclipse code style settings and run auto-format (Ctrl+Shift+F) on new code always before commiting to ensure my nasty personal preferences have not slipped out of subconscious. It also converts all whitespaces consistently to match project settings and sometimes I forget to setup tab-space autoreplacement for external editors. In-place formatting is not that important for me. So that's the exact thing I'm trying to implement: To define an IDE- or project-wide formatting policy and let this control the code style. Let's see how far I can do it :)
Mono-D v0.4.9 - Rough formatting capability
Hi everyone, No, the entire formatting engine is NOT finished yet. :P Anyway I've created a good compromise solution between releasing stuff early and having a fairly nice formatting result: I just let the indenting engine calculate the indents of all lines of the code - and fix all the incorrect indents afterwards. It works quite fast reliable(?) - I hope it won't throw very often + you don't have to worry about resetting your code to an earlier state via [Ctrl+Shift][Z] Indenting only parts of the code is possible either! - So you don't have to worry about your entire code getting messed up probably ;) More info @ http://mono-d.alexanderbothe.com Issues: https://github.com/aBothe/Mono-D/issues
Re: Mono-D v0.4.9 - Rough formatting capability
On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :)
Re: Mono-D v0.4.8
On Wednesday, 16 January 2013 at 07:13:01 UTC, timotheecour wrote: and another bug: (I've updated to the correct stable version as per your instructions, since my last post included). Not sure how to reproduce this bug but it just happened after switching back to MD (i'm on OSX): A fatal error has occurred Details of this error have been automatically sent to Xamarin for analysis. MonoDevelop will now close. System.ArgumentOutOfRangeException: Argument is out of range. at MonoDevelop.D.Formatting.Indentation.IndentStack.Push (Inside inside, Byte keyword, Int32 lineNr, Int32 nSpaces) [0x0] in filename unknown:0 Next time, please dump the upper-most entry of the stack trace only ;) This is fixed now. It'll be part of the next bug-fix release.
Re: Mono-D v0.4.8
On Saturday, 12 January 2013 at 14:28:46 UTC, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com Cheers, Alex Got to bump myself up again. Released a new version - this time with improved code indentation.
Re: Mono-D v0.4.8
On Tuesday, 15 January 2013 at 21:38:55 UTC, timotheecour wrote: On Tuesday, 15 January 2013 at 21:12:21 UTC, alex wrote: On Saturday, 12 January 2013 at 14:28:46 UTC, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com Cheers, Alex Got to bump myself up again. Released a new version - this time with improved code indentation. when upgrading to 0.4.8 i get the error below. Then monodevelop crashes and quits. so it is now unusable. Also, can you describe what you mean by with improved code indentation ? is that code formatting? I've been long hoping for this! Thanks! An error has occurred Error while updating status of command: MonoDevelop.Ide.Commands.ProjectCommands.Run System.MissingMethodException: Method not found: 'MonoDevelop.Projects.ProjectConfiguration.get_ParentItem'. Awesome, again these problems - which MD version do you've got installed? 3.0.6 stable? Then please switch to the mono-d.alexanderbothe.com/stableMD repository 3.1.0 beta? Then switch to the mono-d.alexanderbothe.com repo. If you're having a Mac system and try to use 3.1.1, please downgrade to 3.0.6 stable in order to use the /stableMD repository. I promise, everything will work fine then - I've tested it on Win7 and Mint 13 x86 - It's been launched flawlessly there. With code indent I'm not meaning code formatting but the automated indentation generation after e.g. you've pressed return and it inserts 3 tabs because you're in a method of a class of an other class. @Fil: I haven't changed anything regarding GDB support (yet). I'm sorry but I get myself desperate too about what the guys from MD tend to do sometimes. ;) -- What is linux-vdso.so.1 ?
Mono-D v0.4.7 - Optlink output analysis / Symbol name demangling
Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com Cheers, Alex
Re: Mono-D v0.4.7 - Optlink output analysis / Symbol name demangling
On Saturday, 12 January 2013 at 17:44:54 UTC, Jacob Carlborg wrote: On 2013-01-12 15:28, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com I just tried Mono-D again and I'm having some problems. https://github.com/aBothe/Mono-D/issues * Running an application When I try to run a simple Hello World application it opens a new empty terminal, nothing is printed. I also though that MonoDevelop would run the application and display its output in an internal console view. Uses xterm (at least on linux) to display stuff in an external console. Definitely wasn't my idea. There probably is the possibility to redirect stin/out/err streams into some kind of internal log or so - but then probably the question will rise up whether one can pass input to stdin. Haven't tried it out yet - yes, yet - though Mono-D exists 1.5 years. * Go to definition and autocompletion I have no idea how good these features are supposed to be but to me they work very inconsistently. I have one project where go to definition basically only works for what's in the same file. I have another project where it seems to work fine, mostly. That's where D magic vs. my programming ability comes into the game. I can't and I won't guarantee that both works in all cases (of course not) - all I can do is to make it run in as many cases as possible. There might be couple of strange or uncommon (yes, even common) situations where I haven't thought that these could ever occur. In such cases, please note them down somewhere and tell me what's not working as expected in particular. There is no fancy mixin or template code in these projects. Did you really expect I had finished implementing CTFE so all mixins etc could be resolved? Again, please tell me where it's not working. Since I spend most of my coding time working Mono-D I don't really have time to manage D projects. Completion-related issues may get straight to https://github.com/aBothe/D_Parser please. A few questions: * Does Mono-D do autocompletion or go to definition from external files like files from Phobos and druntime? Yes. And it works for me(tm) - whereas I don't have any dimension of what modules / completion features _advanced_ D users make use of. I mean, as I said, I can't test everything - I need users to do this for me :P * Can Mono-D resolve type inference? Yes. I'm using Mac OS X. This shouldn't be a problem.
Mono-D v0.4.6 - UDA parsing support
Just finished making the parser analyze UDA syntax flawlessly +
Slight profiling statistics display support (dmd exclusive,
unfortunately).
Ah, before I forget it: No, the 'deprecated' attribute syntax à la
[...] void foo() {}
is not supported, only
@... void bar() {}
:-)
http://mono-d.alexanderbothe.com/?p=781
https://github.com/aBothe/Mono-D
https://github.com/aBothe/D_Parser
Re: Mono-D v0.4.6 - UDA parsing support
On Sunday, 6 January 2013 at 17:15:30 UTC, nazriel wrote:
On Sunday, 6 January 2013 at 17:10:17 UTC, alex wrote:
Just finished making the parser analyze UDA syntax flawlessly
+ Slight profiling statistics display support (dmd exclusive,
unfortunately).
Ah, before I forget it: No, the 'deprecated' attribute syntax
à la
[...] void foo() {}
is not supported, only
@... void bar() {}
:-)
http://mono-d.alexanderbothe.com/?p=781
https://github.com/aBothe/Mono-D
https://github.com/aBothe/D_Parser
By depracated you mean new sytnax for adding messages to
deprecate blocks introduced by yebblies?
deprecated(Don't use anymoar)
void func() {}?
Oh, no you actually can type
deprecated(Don't do this because!) void oldFoo() {}
now.
With the 'deprecated' attribute syntax I meant this [..]
attribute syntax, nothing else. :)
Re: Mono-D v0.4.6 - UDA parsing support
On Sunday, 6 January 2013 at 17:37:05 UTC, Philippe Sigaud wrote:
Oh, no you actually can type
deprecated(Don't do this because!) void oldFoo() {}
now.
You can? Wow, yet another change that was not in the docs? I'm
becoming
bitter, here.
With the 'deprecated' attribute syntax I meant this [..]
attribute syntax,
nothing else. :)
OK.
Good job, Alexander.
There should be a dedicated list of changes made to the spec
sheets. Or even a dedicated repository, book, wiki or whatsoever
to make all changes purely clear for everyone.
@Philippe: I've found out about this syntax _just_ because there
were hundreds of errors thrown out while parsing though phobos -
So in the end, I'm designing the parser more after phobos than
the actual spec. Mentally insane, but well..it's just another D
thing.
Re: XING Gruppe D Programming Language - XING group D Programming Language
On Wednesday, 2 January 2013 at 18:38:08 UTC, notna wrote: On 02.01.2013 19:24, Chris wrote: A D-ating site? :-) :D Hopefully on the way to something like that... then mainly for business dating ;) Ha, cool, thanks for creating this group!
Mono-D v0.4.5
Hi everyone, I've just uploaded a new version of Mono-D. This time again several bug fixes, improvements..the usual stuff ;) For a changelog, see the first link to the project blog. Oh and merry Christmas to each of you - may there be a small social leftover besides the entire x-mas commerce we've got to experience during these days ;-D http://mono-d.alexanderbothe.com https://github.com/aBothe/Mono-D/issues https://github.com/aBothe/D_Parser/issues
Re: Getting ready for 2.061
On 22-12-2012 06:11, Jonathan M Davis wrote: On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote: We plan to start building a new release on Sunday evening. To do so (pursuant to the embryonic process we're putting in place), at that time we'll create a new branch called staging for each of dmd, druntime, and phobos. All contributors - over the weekend please ping reviewers on what you believe are pull requests with a high importance*urgency product. Once we branch into staging, pull requests will only be merged into master. https://github.com/D-Programming-Language/dmd/pull/1287 really should be resolved prior to 2.061, or we're going to be introducing a compiler flag (-di) which we're probably then going to turn around and deprecate (and making deprecations warn by default instead of giving you an error will be _huge_ step forward in our ability to manage deprecations without breaking people's code). - Jonathan M Davis +1 to this. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Mono-D v0.4.4 Template mixins, completion improvements
Hi everyone, I've implemented one of the last missing things regarding code completion (except those huge remaining fields in the expression evaluation, so correct traitCTFE handling etc.) now. Though I doubt that everything is interpreted correctly I wrote a bunch of unit tests that passed successfully - imho another step in the right direction. Now trying to begin with the code formatter.. but unlike installing new completion features this will take longer, I guess :) http://mono-d.alexanderbothe.com http://d-ide.sourceforge.net https://github.com/aBothe/Mono-D/issues
Mono-D 0.4.3: Mixins, declaration constraints, static if() analysis
Imho some really nice improvements concerning the code completion ability of Mono-D/D-IDE. And no, CTFE as well as template mixins are NOT implemented yet ;) http://mono-d.alexanderbothe.com https://github.com/aBothe/Mono-D/issues https://github.com/aBothe/D_Parser/issues Furthermore, any ideas how to boost up expression evaluation, i.e. mixin evaluation performance? I've made a hashing function which calculates relatively unique integer values for each expression - but for now I'm not really sure how to dimension an inter-parse caching, so the caching of an expression value as long as there are no changes made to either the expression itself or some base expression the actual expression may depends on. Also for CTFE, I want to establish excessive caching so I don't have to execute the same function with the equal arguments more than once. Not that the mixin evaluation performance is _that_ weak, but perhaps for thinking in terms of having CTFE and all the stuff implemented soon.. Is dmd caching mixin results when having one evaluated once?
Re: Mono-D 0.4.3: Mixins, declaration constraints, static if() analysis
On Thursday, 22 November 2012 at 20:16:10 UTC, Jacob Carlborg wrote: On 2012-11-22 20:19, alex wrote: Imho some really nice improvements concerning the code completion ability of Mono-D/D-IDE. And no, CTFE as well as template mixins are NOT implemented yet ;) http://mono-d.alexanderbothe.com https://github.com/aBothe/Mono-D/issues https://github.com/aBothe/D_Parser/issues How do I update to the latest version? The main page says: For MonoDevelop 3.0.5 and custom builds, also see the installation page for further download steps! On the installation page it says: If you’re using MonoDevelop on Windows/Mac, download the latest .mpack file here. If I click here it links to http://mono-d.alexanderbothe.com/?p=591, which basically is the main page. BTW, on Mac OS X the Add-in Manager is located on the MonoDevelop menu. MonoDevelop 3.0.5 just released as stable version, and my site hasn't been updated yet - just take the .mpack link I've put in on the top of my blog..
Mono-D v0.4.2 Project building fixes
..and the round goes on with a new bunch of fundamental fixes and improvements :) http://mono-d.alexanderbothe.com Issues go here https://github.com/aBothe/Mono-D/issues as usual, and the direct download for all Mac/Windows users that have MonoDevelop 3.0.4.7: http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.2.0_MD3.0.4.7.mpack
Re: Mono-D v0.4.1.9
On Wednesday, 7 November 2012 at 12:48:30 UTC, Bruno Medeiros wrote: On 24/08/2012 00:18, alex wrote: Hi everyone, Right after the GSoC finished (I'm really sure I passed :)), I've just found more time to improve things drastically: I also have to extend my congratulations for the work you have done. I tried Mono-D several releases ago (before Summmer), and even then it was already very good in its semantic functionality (autocomplete etc.). It was the only D IDE to come anywhere close to what DDT and Descent had in terms of semantic functionality (sorry VisualD and others :P ), and even more, it actually didn't just come close but actually surpassed it significantly! Thanks! Hopefully I can release the new 0.4.1.9 version today :)
Mono-D v0.4.1.9
Between all these discussions about new D language features :) A new version just released. For any info, see http://mono-d.alexanderbothe.com Issues go here: https://github.com/aBothe/Mono-D/issues If you've downloaded MonoDevelop from download.monodevelop.com, please download the latest addin directly from http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.9_MD3.0.4.7.mpack
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:55:06 UTC, Sönke Ludwig wrote:
Am 06.11.2012 09:26, schrieb Walter Bright:
On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we
keep the
syntax closer to normal attributes and other
languages(*)? I see a lot of arguments for doing that, with
the only
counter-argument that they would be in the same namespace as
the
built-in attributes (which should not be that bad, as this is
very low
level language stuff).
(*) i.e. @mytype or @(string) and without the '[]'
We can debate the syntax. I don't have a store set by this
one. I was
more interested in getting the semantics right. Anyhow, it's
nice to
have a working prototype to experiment with rather than a
paper airplane.
Definitely! Thanks a lot for tackling this, to me this seems
like
something that can get a real killer feature for the language!
@test
void myUnittest()
{
}
Uh yeah, that would be awesome!
Re: Objects in a Templated World
On 30-10-2012 19:23, Jesse Phillips wrote: I've written an article which goes over templates and objects. http://nascent.freeshell.org/programming/D/objectTemplate.php On a similar note I've republished _Learning to Program Using D_. Not a whole lot of change on the content front. Some expansions on existing chapters and a few fillers were added. Still very unfinished at around 50 pages. http://nascent.freeshell.org/programming/D/LearningWithD/ I include a generated PDF and a pre.tex file. What is probably of more interest to others writing D books in Latex is I have a program which handles building running and capturing output for the final tex file. It is very picky about formatting and can't handle file includes and probably many other fancy Latex options but it is mine so :P https://github.com/JesseKPhillips/listings-dlang-extractor And finally code uses the listings package, for which I have provided a style file to handle highlighting. https://github.com/JesseKPhillips/dlang-latex-listings I think you should cover C#. It allows virtual generic methods in its implementation of reified generics by relying on the JIT. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Mono-D v0.4.1.7
On Sunday, 21 October 2012 at 20:39:17 UTC, F i L wrote:
On Sunday, 21 October 2012 at 17:37:17 UTC, alex wrote:
This behaviour is terribly inreproducable..Sometimes it tends
to not have any plan of what I'm typing, but mostly (and quite
only) it actually knows what I want to have in my completion
list..
If you're able to figure out a good way of having it that
buggy, please tell me.
In the mean time, if you want to switch to older versions,
just check out
http://mono-d.alexanderbothe.com/repo
Thanks Alex. As far as reproducing the error, all I have to do
is create a new test project, and change the 'main.d' file to
look like:
module main;
class Test
{
int x = 10;
}
void main()
{
auto t = new Test();
t... // wrong options, you know the situation
}
I'll try and find a situation where it works, and report before
I Switch back to an older version.
Fixed it. Was something with manual SO prevention and a missing
declaration conditition implementation..but now it works
definitely, see:
https://github.com/aBothe/Mono-D/issues/161
I've put it in Mono-D v0.4.1.7
Re: Mono-D v0.4.1.6
On Sunday, 21 October 2012 at 20:39:17 UTC, F i L wrote:
On Sunday, 21 October 2012 at 17:37:17 UTC, alex wrote:
This behaviour is terribly inreproducable..Sometimes it tends
to not have any plan of what I'm typing, but mostly (and quite
only) it actually knows what I want to have in my completion
list..
If you're able to figure out a good way of having it that
buggy, please tell me.
In the mean time, if you want to switch to older versions,
just check out
http://mono-d.alexanderbothe.com/repo
Thanks Alex. As far as reproducing the error, all I have to do
is create a new test project, and change the 'main.d' file to
look like:
module main;
class Test
{
int x = 10;
}
void main()
{
auto t = new Test();
t... // wrong options, you know the situation
}
I'll try and find a situation where it works, and report before
I Switch back to an older version.
Just tried it and had the same strange issue behaviour a couple
of times - but as I restarted MD, the issue wasn't there
anymore..neither in 3.0.4.8 nor 3.0.4.7 .. seems to be a very
rare issue only..and therewith a border case 'only'
Re: Mono-D v0.4.1.6
On Sunday, 21 October 2012 at 01:31:55 UTC, F i L wrote: On Sunday, 21 October 2012 at 01:14:58 UTC, alex wrote: On Saturday, 20 October 2012 at 23:49:03 UTC, F i L wrote: The symbols themselves show up fine, but any class/struct members don't show up. I have no idea why it's suddenly working again. I've uploaded a new http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.6_MD3.0.4.7.mpack That didn't change anything on my end. Still the same intellisense options after the install. BTW, by installing from the file, will that stop me from receiving online updates? Strange. And yes, installing the mpack manually isn't enabling auto-updates..but due to the awful updating policy I had to open a second repository just for MD 3.0.4.7 ..and at this point I just say *uck it, I don't care :D
Re: Mono-D v0.4.1.6
This behaviour is terribly inreproducable..Sometimes it tends to not have any plan of what I'm typing, but mostly (and quite only) it actually knows what I want to have in my completion list.. If you're able to figure out a good way of having it that buggy, please tell me. In the mean time, if you want to switch to older versions, just check out http://mono-d.alexanderbothe.com/repo
Mono-D v0.4.1.6
Aaaand Mono-D 0.4.1.6 released.. please check out http://mono-d.alexanderbothe.com/?p=645 .. this time, I'm too lazy to enum any details but one larger improvement: The new way of renaming symbols. It can be done a bit more comfortable via relatively nice designed dialog boxes now - I even appended a screenshot to the post :)
Re: Mono-D v0.4.1.6
On Saturday, 20 October 2012 at 23:49:03 UTC, F i L wrote: On Saturday, 20 October 2012 at 22:12:57 UTC, alex wrote: Aaaand Mono-D 0.4.1.6 released.. please check out http://mono-d.alexanderbothe.com/?p=645 .. this time, I'm too lazy to enum any details but one larger improvement: The new way of renaming symbols. It can be done a bit more comfortable via relatively nice designed dialog boxes now - I even appended a screenshot to the post :) hmmm... with the latest update (and possibly the previous one, I hadn't updated since the first post of this thread), the intellisense completely fails. Every symbol's intellisense options read: alingof init mangleof sizeof stringof The symbols themselves show up fine, but any class/struct members don't show up. Oh man...this is awful. (Lol I think as I'm writing this I'm having a déja-vu) It's even worse that it's showing the correct items only sometimes, so sometimes only the general ones (alignof etc.), and sometimes the correct ones..
Re: Mono-D v0.4.1.6
On Saturday, 20 October 2012 at 23:49:03 UTC, F i L wrote: The symbols themselves show up fine, but any class/struct members don't show up. I have no idea why it's suddenly working again. I've uploaded a new http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.6_MD3.0.4.7.mpack
Blog post: Demystifying Garbage Collectors
http://xtzgzorex.wordpress.com/2012/10/11/demystifying-garbage-collectors/ Essentially an explanation of garbage collection for the layman programmer. Though, it does assume some familiarity with C and memory management. It's an abstract article not particularly specific to any GC implementation, but I figured I'd post it here anyway in case anyone's interested. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Mono-D v0.4.1.4 Completion improvement, again
Hi everyone, Though I primarily wanted to do the formatter first I’ve made some changes to the completion engine again: - Found mistake in the D specs again: It’s unimportant whether there are only members that are named as the parent template but whether there ARE members called like the template – so if there are other members, it’s not throwing a compilation error. - Got to!string(…) finally be recognized as a string value – Implemented a first approach on how to find templates’ child items that are named like the actual template and replace that template by that equally-named child. - Completion issue when handling Exception objects inside catch() blocks - Small typeid() completion issue - Solved several UFCS issues with template methods that are invoked via ufcs. - Several micro-optimizations + Way better template parameter/instance handling - Fixed completion issue with auto-returning functions - Great internal redesign / put some class-defining sources into subdirectories - fixed import statement generation/NewExpression handling - Mini tooltip bug. recognized that my code is smarter than I originally expected. *cough cough* So far. I’ve updated the link to the package for MD 3.0.3.5, too. I hope that there aren’t so many (new) crashs and exceptions/bugs whatever anymore, but let’s see :) http://mono-d.alexanderbothe.com https://github.com/aBothe/Mono-D/issues
Re: GC vs. Manual Memory Management Real World Comparison
On 05-09-2012 13:03, Benjamin Thaut wrote: I rewrote a 3d game I created during my studies with D 2.0 to manual memory mangement. If I'm not studying I'm working in the 3d Engine deparement of Havok. As I needed to pratice manual memory management and did want to get rid of the GC in D for quite some time, I did go through all this effort to create a GC free version of my game. The results are: DMD GC Version: 71 FPS, 14.0 ms frametime GDC GC Version: 128.6 FPS, 7.72 ms frametime DMD MMM Version: 142.8 FPS, 7.02 ms frametime GC collection times: DMD GC Version: 8.9 ms GDC GC Version: 4.1 ms As you see the manual managed version is twice as fast as the garbage collected one. Even the highly optimized version created with GDC is still slower the the manual memory management. You can find the full article at: http://3d.benjamin-thaut.de/?p=20#more-20 Feedback is welcome. Kind Regards Benjamin Thaut Is source code available anywhere? Also, I have to point out that programming for a garbage collected runtime is very different from doing manual memory management. The same patterns don't apply, and you optimize in different ways. For instance, when using a GC, it is very recommendable that you allocate up front and use object pooling - and most importantly, don't allocate at all during your render loop. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: GC vs. Manual Memory Management Real World Comparison
On 05-09-2012 13:19, Benjamin Thaut wrote: Am 05.09.2012 13:10, schrieb Alex Rønne Petersen: Is source code available anywhere? Also, I have to point out that programming for a garbage collected runtime is very different from doing manual memory management. The same patterns don't apply, and you optimize in different ways. For instance, when using a GC, it is very recommendable that you allocate up front and use object pooling - and most importantly, don't allocate at all during your render loop. The sourcecode is not aviable yet, as it is in a repository of my university, but I can zip it and upload the current version if that is wanted. But it currently does only support Windows and does not have any setup instructions yet. I do object pooling in both versions, as in game developement you usually don't allocate during the frame. But still in the GC version you have the problem that way to many parts of the language allocate and you don't event notice it when using the GC. Just to clarify, I'm into 3d engine developement since about 7 years now. So I'm not a newcomer to the subject. Kind Regards Benjamin Thaut Sure, I just want to point out that it's a problem with the language (GC allocations being very non-obvious) as opposed to the nature of GC. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
