Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
At first, thank you. There is an issue with Diet templates highlighting. It's very poor. Just compare Mono-D 2.0.1/Xamarian Studio 5.0 - http://a-rei.ru/eNhp Sublime Text 3 - http://a-rei.ru/vuoY
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 08:12:50 UTC, Jack Applegame wrote: At first, thank you. There is an issue with Diet templates highlighting. It's very poor. Just compare Mono-D 2.0.1/Xamarian Studio 5.0 - http://a-rei.ru/eNhp Sublime Text 3 - http://a-rei.ru/vuoY Hmm, normally, this stuff should've been highlighted as well. See http://mono-d.alexanderbothe.com/diet-template-syntax-highlighting/ :) But thanks for noticing that regression.
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 11:28:25 UTC, Alexander Bothe wrote: But thanks for noticing that regression. No, it actually is working. Your file has to end with '.dt' to have proper highlighting. A screenshot I just took: http://i.imgur.com/KaWAKgW.png
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 11:37:58 UTC, Alexander Bothe wrote: On Saturday, 3 May 2014 at 11:28:25 UTC, Alexander Bothe wrote: But thanks for noticing that regression. No, it actually is working. Your file has to end with '.dt' to have proper highlighting. A screenshot I just took: http://i.imgur.com/KaWAKgW.png Strange. What is wrong? editor - http://a-rei.ru/meJf about - http://a-rei.ru/RAuW add-in manager - http://a-rei.ru/jIrf
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 13:21:24 UTC, Jack Applegame wrote: Strange. What is wrong? editor - http://a-rei.ru/meJf about - http://a-rei.ru/RAuW add-in manager - http://a-rei.ru/jIrf Nothing is wrong with that - except that in the current release, the inline-D syntax highlighting only triggers after a - or # (double space + minus/hash), not after a \t- (tab + minus) I've corrected this now :-) https://github.com/aBothe/Mono-D/commit/52eaa924385fb55685e2e11d1500dedf053c9c18
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Wednesday, 30 April 2014 at 20:15:37 UTC, Alexander Bothe wrote: Hi everyone, there's a new XamarinStudio version upcoming. And just as usual, I've just downloaded the bleeding-edge release candidate and made Mono-D run on it :P For the next couple of days, you'll only be able to get Mono-D from the repo I've mentioned in the release note, as XamarinStudio's online addin system isn't ready for the new major version yet. Furthermore, there have been some smaller changes improvements to the completion functionality again. There's also upcoming dustmite support where you'll be able to invoke dustmite from within Mono-D. http://mono-d.alexanderbothe.com/mono-d-2-0-for-xamarinstudio-5-0/ Hopefully, I can release the new XamarinStudio/MonoDevelop version on Linux as well. Someone mentioned an API freeze for the next couple of XS/MD versions, so chances are good that there's no hassle with broken Mono-D's for the next months. Enjoy! Hi Alex, Great Job! I'm not seeing any more the icons in the document outline pad: is it expected? Thanks, Paolo
Re: Unit-threaded v0.4.0 released
Version v0.4.3 now. New: . Tests can be run in random (single-threaded) order. A seed can be specified. . unittest blocks are registered at compile-time. This mean each block/function is its own test case. Before all blocks from a module were a test case. Atila On Wednesday, 23 April 2014 at 07:42:57 UTC, Atila Neves wrote: http://code.dlang.org/packages/unit-threaded . The @HiddenTest UDA now takes a compile-time string meant to be a bug id or other reason why the test is hidden. Unfortunately that means previous code using it needs to add a string or it'll fail to compile . The new @ShouldFail UDA also takes a compile-time string for the same reason. This fauses a test to fail unless it throws. Harder to sweep under the carpet than @HiddenTest . On the sweeping front, the number of hidden tests is now reported in yellow . Exceptions that aren't a descendant of unit_threaded.check.UnitTestException display a stack trace. This is for easier debugging in case an unexpected exception is thrown . The one bug I knew of was fixed Atila
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 17:09:41 UTC, Paolo Invernizzi wrote: I'm not seeing any more the icons in the document outline pad: is it expected? must be a regression as well. Gonna check it.
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 17:09:41 UTC, Paolo Invernizzi wrote: I'm not seeing any more the icons in the document outline pad: is it expected? Fixed it in v2.0.2
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 18:55:44 UTC, Alexander Bothe wrote: On Saturday, 3 May 2014 at 17:09:41 UTC, Paolo Invernizzi wrote: I'm not seeing any more the icons in the document outline pad: is it expected? Fixed it in v2.0.2 Thank you! /Paolo
Re: More radical ideas about gc and reference counting
On Friday, 2 May 2014 at 15:03:47 UTC, Andrei Alexandrescu wrote: On 5/2/14, 1:34 AM, Paolo Invernizzi wrote: On Thursday, 1 May 2014 at 21:29:19 UTC, Andrei Alexandrescu wrote: On 5/1/14, 1:19 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, May 01, 2014 at 01:03:06PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 5/1/14, 12:52 PM, Nordlöw wrote: into a class. I'm inclined to say that we should outright prohibit that, That can't happen. Why is that? (1) Too much breakage, (2) would disallow a ton of correct code, (3) no reasonable alternative to propose. We'd essentially hang our users out to dry. -- Andrei Isn't this what we're already doing by (eventually) getting rid of class dtors? Not even close. (1) A lot less breakage, (2) disallowed code was already not guaranteed to work, (3) reasonable alternatives exist. Andrei I have 165k lines of code to review for that change... I would not call it a minor breakage... I didn't. I said a lot less that straight out disallowing struct members. -- Andrei I would also add one point, just because it is not so obvious: I'll be more than happy to review my company code, if the proposed solutions about finalisation in class/struct turn out to take D one step forward being a better programming language. /Paolo
Re: Reopening the debate about non-nullable-by-default: initialization of member fields
Jonathan M Davis: Idan Arye: We are all sick and tired of this debate, but today I've seen a question in Stack Exchange's Programmers board that raises a point I don't recall being discussed here: Yeah, I brought this up before, and it's one of the reasons why I'm against non-nullable by default. I think that problem was raised plenty of times during the discussions about non-nullable. And I think this paper (and successive ones) solve enough the problems: http://research.microsoft.com/en-us/um/people/leino/papers/krml109.pdf And aren't the ideas about cooked/uncooked (referred as raw in the paper) already partially present in D? Bye, bearophile
Re: More radical ideas about gc and reference counting
Am 30.04.2014 22:21, schrieb Andrei Alexandrescu: Walter and I have had a long chat in which we figured our current offering of abstractions could be improved. Here are some thoughts. There's a lot of work ahead of us on that and I wanted to make sure we're getting full community buy-in and backup. First off, we're considering eliminating destructor calls from within the GC entirely. It makes for a faster and better GC, but the real reason here is that destructors are philosophically bankrupt in a GC environment. I think there's no need to argue that in this community. The GC never guarantees calling destructors even today, so this decision would be just a point in the definition space (albeit an extreme one). That means classes that need cleanup (either directly or by having fields that are structs with destructors) would need to garner that by other means, such as reference counting or manual. We're considering deprecating ~this() for classes in the future. Also, we're considering a revamp of built-in slices, as follows. Slices of types without destructors stay as they are. Slices T[] of structs with destructors shall be silently lowered into RCSlice!T, defined inside object.d. That type would occupy THREE words, one of which being a pointer to a reference count. That type would redefine all slice primitives to update the reference count accordingly. RCSlice!T will not convert implicitly to void[]. Explicit cast(void[]) will be allowed, and will ignore the reference count (so if a void[] extracted from a T[] via a cast outlives all slices, dangling pointers will ensue). I foresee any number of theoretical and practical issues with this approach. Let's discuss some of them here. Thanks, Andrei Honestly, that sounds like the entierly wrong apporach to me. Your approaching the problem in this way: We can not implement a propper GC in D because the language design prevents us from doing so. So lets remove destructors to migate the issue of false pointers. While the approach should be. The language does not allow to implement a propper GC (anything else then dirty mark sweep), what needs to be changed to allow a implementation of a more sophisticated GC. Also let me tell you that at work we have a large C# codebase which heavily relies on resource management. So basically every class in there inherits from C#'s IDisposable interface which is used to manually call the finalizer on the class (but the C# GC will also call that finalizer!). Basically the entire codebase feels like manual memory management. You have to think about manually destroying every class and the entire advantage of having a GC, e.g. not having to think about memory management and thus beeing more productive, vanished. It really feels like writing C++ with C# syntax. Do we really want that for D? And what if I want unsafe slices of structs with destructors, for performance? Maybe I perfectly know that the memory behind the slice will outlive the slice, and I don't want the overhead of all the reference counthing behind it? If you actually deprecate ~this, there would be two options for me. 1) Migrate my entire codebase to some user defiend finalizer function (which doesn't have compiler support), which would be a lot of work. 2) Quit D. (which is becomeing more and more an option when reading the recent news group discussions.) -- Kind Regards Benjamin Thaut
Re: More radical ideas about gc and reference counting
feels like writing C++ with C# syntax. Ahem. C++ has RAII k thanks. C++ C# Proof.
Re: Reopening the debate about non-nullable-by-default: initialization of member fields
I would allow this bug. This also happens with 'final' member in Java, and there you expect the value to not be null. A rule of thumb should be to never call virtual methods from inside of a constructor. Bad things happen.
Re: More radical ideas about gc and reference counting
On Friday, 2 May 2014 at 00:45:42 UTC, Andrei Alexandrescu wrote: Here's where the point derails. A struct may be preexisting; the decision to define a destructor for it and the decision to use polymorphism for an object that needs that structure are most of the time distinct. Andrei I wonder how common the pattern of putting a struct with a destructor in a class actually is. It might be a case for defining data structures with GC allocation rather than reference counting (as in std.container). I suppose a choice of allocator will change this quite a lot. That which is allocated with reference counting could uniquely hold its container member and then call the destructor when it dies, or similar. I find it kind of a funny thing to put something like a File inside of a class. I have always seen the mix of GC and resource management as more managing resources like Files in scopes and reading data from the resources which turn into objects in memory which are garbage collected. Not allocating garbage collected objects which contain resources.
Re: More radical ideas about gc and reference counting
Am 01.05.2014 19:35, schrieb Marc Schütz schue...@gmx.net: But conceptually, this is _not_ the same as classes! As others have mentioned, it's possible to created structs with `new`, or have them in dynamic arrays, as well as managing class objects manually. Maybe the language should have some way to distinguish between GC-managed and manually-managed objects, preferably in the type system. Then it could be statically checked whether an object is supposed to be GC-managed, and consequentially shouldn't have a destructor. The difference between classes and structs should then be reference vs. value semantics, and polymorphic vs static (which correlate nicely). It should, however, not imply whether the object is managed by the GC or not. Some kind of ownership mechanism would be more suited for that. +1
Progress on Adam Wilson's Graphics API?
Is there any progress on the graphics API Adam Wilson is working on?
Re: More radical ideas about gc and reference counting
On Friday, 2 May 2014 at 20:59:46 UTC, monarch_dodra wrote: Yeah, you have to read the fine print: collection implies destruction *but* no guarantees the collection will actually ever happen. Which make destructors dangerous constructs. It means you now risk getting random bugs-reports after deployment. Acceptable for a hobby language, not acceptable for a systems programming language.
The Current Status of DQt
Hello everyone. From time to time, people ask in the newsgroup and also IRC about Qt bindings for D, so I thought it would be a good idea to give people an update on where my own bindings stand. First, if you want to take a look at my code as it stands, you can get it here. https://github.com/w0rp/dqt It depends on two other repositories which are also hosted on GitHub, and which are mentioned in the readme. Building dqt itself isn't that great, as I ran into some issues with DUB, but Sönke has since addressed my primary issue, so it may now be possible to build the project with the master branch version of DUB. Here is what I have done. 1. These bindings use SMOKE, which is a library which can be used to generate bindings for C++ libraries. The 'smokeqt' library does a Hell of a lot of work already for me. Everything I have is written in about 99% D. The just SMOKE part I have put in a separate repo, and it could potentially be used for wrapping other C++ libraries. 2. The majority of classes from Qt are generated as D classes which wrap around the C++ classes. This allows for polymorphism, at the expense of some additional resource management at times. (You can disable garbage collection and let Qt take over.) 3. Calling virtual method overrides from C++ isn't done yet, but I pretty much know how to do it, and there is some code in place which does about half of the job. 4. You can draw windows and so on with a DQt program. (I drew a gridlayout with a few buttons for a calculator successfully) There are some important things left to do. 1. I have not accounted for multiple inheritance yet, which Qt uses. My idea was to nominate one class as the concrete class which is inherited (QObject) and then turn other classes into interaces which have seperate classes for implementation. (QPaintDevice) 2. I have not yet implemented signals and slots. Two options for this involve generating QMetaObject instances for classes, possibly via template mixins, which do what 'moc' does for C++. A second option is to use Qt5 for the library and to force all signals and slots behaviour to go through functions, as Qt5 can use function pointers as slots. (I prefer option 2.) So, I am eager to hear what people think about all of this. Does anyone like the work that I have done, and will it be useful? Have I committed some terrible crime against nature, for which I must be punished? Does anyone have any ideas about things that could be improved, or where to go next? Please, let me know. My progress has been somewhat slow in writing all of this, as I have been writing it mostly in the evenings, moslty during weekdays, after my day job. I've also been running into problems for which there are no easy answers, possibly no documentation for, and so on. So a great deal of my time has been spent more on thinking of what to do next, rather than writing anything. (It took me possibly months to come up with the resource management scheme that I have now.)
Re: More radical ideas about gc and reference counting
On 2014-05-01 17:35:36 +, Marc Schütz schue...@gmx.net said: Maybe the language should have some way to distinguish between GC-managed and manually-managed objects, preferably in the type system. Then it could be statically checked whether an object is supposed to be GC-managed, and consequentially shouldn't have a destructor. Or turn the rule on its head: make it so having a destructor makes the heap memory block reference counted. With this adding a destructor always cause deterministic destruction. The compiler knows statically whether a struct has a destructor. For a class you need a runtime trick because the root object which can be either. Use a virtual call or a magic value in the reference count field to handle the reference count management. You also need a way to tag a class to be guarantied it has no derived class with a destructor (to provide a static proof for the compiler it can omit ARC code), perhaps @disable ~this(). Then remains the problem of cycles. It could be a hard error if the destructor is @safe (error thrown when the GC collects it). The destructor could be allowed to run (in any thread) if the destructor is @system or @trusted. The interesting thing with this is that the current D semantics are preserved, destructors become deterministic (except in the presence of cycles, which the GC will detect for you), and if you're manipulating pointers to pure memory (memory blocks having no destructor) there's no ARC overhead. And finally, no new pointer attributes; Walter will like this last one. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: More radical ideas about gc and reference counting
Am 03.05.2014 10:57, schrieb froglegs: feels like writing C++ with C# syntax. Ahem. C++ has RAII k thanks. C++ C# Proof. Which does not work across threads, relies on stack allocations and has issues if cleaning a resource implies having a not handled exception on the destructor of the RAII class. I rather make use of using and FP resource handling via lambdas. -- Paulo
Running Phobos unit tests in threads: I have data
So I tried using unit-threaded to run Phobos unit tests again and had problems (which I'll look into later) with its compile-time reflection. Then I realised I was an idiot since I don't need to reflect on anything: all Phobos tests are in unittest blocks so all I need to do is include them in the build and unit-threaded will run them for me. I tried a basic sanity check by running them in one thread only with the -s option and got a segfault, and a failing test before that. None of this should happen, and I'll be taking a look at that as well. But I carried on by removing the troublesome modules from the build. These turned out to be: std.datetime (fails) std.process (fails and causes the segfault) std.stdio (fails) All the others pass in single threaded mode. After this I tried using threads and std.parallelism failed, so I took that away from the build as well. Another thing to mention is that although the tests are running in threads, since when I wrote the library the getUnitTests __traits wasn't available (and since then I wasn't interested in using it), each module's unit tests run as one test. So they only interleave with other modules, not with each other. Running in one thread took 39 +/- 1 seconds. Running in 8 threads took... ~41 seconds. Oops. I noticed some tests take a lot longer so I tried removing those. They were: std.file std.conv std.regex std.random std.container std.xml std.utf std.numeric std.uuid std.exception I also removed any modules that were likely to be problematic like std.concurrency and std.socket. With the reduced sample size the results were: 1 thread: ~1.9s 8 threads: 4.1s +/- 0.2 So the whole threading thing isn't looking so great. Or at least not how I implemented it. This got me thinking about my own projects. The tests run so fast I never really paid attention to how fast they were running. I compared running the unit tests in Cerealed in one or more threads and got the same result: running in one thread was faster. I have to look to be sure but maybe the bottleneck is output. As in actually printing the results to the screen. I had to jump through a few hoops to make sure the output wasn't interleaved, and in the end decided to have one thread be responsible for that, with the tests sending it output messages. For reference, I copied all of the std/*.d modules into a local std directory, compiled all of them with dmd -unittest -c, then used this as the build command: dmd -unittest -I~/coding/d/unit-threaded/source ut.d std/algorithm.o std/array.o std/ascii.o std/base64.o std/bigint.o std/bitmanip.o std/compiler.o std/complex.o std/container.o std/cstream.o std/csv.o std/demangle.o std/encoding.o std/format.o std/functional.o std/getopt.o std/json.o std/math.o std/mathspecial.o std/metastrings.o std/mmfile.o std/numeric.o std/outbuffer.o std/range.o std/signals.o std/stdint.o std/stdiobase.o std/stream.o std/string.o std/syserror.o std/system.o std/traits.o std/typecons.o std/typelist.o std/typetuple.o std/uri.o std/variant.o std/zip.o std/zlib.o libunit-threaded.a -ofphobos_ut I got libunit-threaded.a by running dub build in the root directory of unit-threaded. I might just implement a random order option now. Hmm. Atila
Re: Running Phobos unit tests in threads: I have data
I turned off all output to check. It was still slower with
multiple threads. That was the only weird thing I was doing I
could think of as the cause. Otherwise it's just a foreach(test;
tests.parallel) { test(); }.
Atila
On Saturday, 3 May 2014 at 11:54:55 UTC, Atila Neves wrote:
So I tried using unit-threaded to run Phobos unit tests again
and had problems (which I'll look into later) with its
compile-time reflection. Then I realised I was an idiot since I
don't need to reflect on anything: all Phobos tests are in
unittest blocks so all I need to do is include them in the
build and unit-threaded will run them for me.
I tried a basic sanity check by running them in one thread only
with the -s option and got a segfault, and a failing test
before that. None of this should happen, and I'll be taking a
look at that as well.
But I carried on by removing the troublesome modules from the
build. These turned out to be:
std.datetime (fails)
std.process (fails and causes the segfault)
std.stdio (fails)
All the others pass in single threaded mode. After this I tried
using threads and std.parallelism failed, so I took that away
from the build as well.
Another thing to mention is that although the tests are running
in threads, since when I wrote the library the getUnitTests
__traits wasn't available (and since then I wasn't interested
in using it), each module's unit tests run as one test. So they
only interleave with other modules, not with each other.
Running in one thread took 39 +/- 1 seconds.
Running in 8 threads took... ~41 seconds.
Oops. I noticed some tests take a lot longer so I tried
removing those. They were:
std.file
std.conv
std.regex
std.random
std.container
std.xml
std.utf
std.numeric
std.uuid
std.exception
I also removed any modules that were likely to be problematic
like std.concurrency and std.socket. With the reduced sample
size the results were:
1 thread: ~1.9s
8 threads: 4.1s +/- 0.2
So the whole threading thing isn't looking so great. Or at
least not how I implemented it. This got me thinking about my
own projects. The tests run so fast I never really paid
attention to how fast they were running. I compared running the
unit tests in Cerealed in one or more threads and got the same
result: running in one thread was faster.
I have to look to be sure but maybe the bottleneck is output.
As in actually printing the results to the screen. I had to
jump through a few hoops to make sure the output wasn't
interleaved, and in the end decided to have one thread be
responsible for that, with the tests sending it output messages.
For reference, I copied all of the std/*.d modules into a local
std directory, compiled all of them with dmd -unittest -c, then
used this as the build command:
dmd -unittest -I~/coding/d/unit-threaded/source ut.d
std/algorithm.o std/array.o std/ascii.o std/base64.o
std/bigint.o std/bitmanip.o std/compiler.o std/complex.o
std/container.o std/cstream.o std/csv.o std/demangle.o
std/encoding.o std/format.o std/functional.o std/getopt.o
std/json.o std/math.o std/mathspecial.o std/metastrings.o
std/mmfile.o std/numeric.o std/outbuffer.o std/range.o
std/signals.o std/stdint.o std/stdiobase.o std/stream.o
std/string.o std/syserror.o std/system.o std/traits.o
std/typecons.o std/typelist.o std/typetuple.o std/uri.o
std/variant.o std/zip.o std/zlib.o libunit-threaded.a
-ofphobos_ut
I got libunit-threaded.a by running dub build in the root
directory of unit-threaded.
I might just implement a random order option now. Hmm.
Atila
Re: Running Phobos unit tests in threads: I have data
Out of curiosity are you on Windows? No, Arch Linux 64-bit. I also just noticed a glaring threading bug in my code as well that somehow's never turned up. This is not a good day. Atila
Re: Running Phobos unit tests in threads: I have data
On Saturday, 3 May 2014 at 12:08:56 UTC, Atila Neves wrote:
I turned off all output to check. It was still slower with
multiple threads. That was the only weird thing I was doing I
could think of as the cause. Otherwise it's just a
foreach(test; tests.parallel) { test(); }.
Atila
On Saturday, 3 May 2014 at 11:54:55 UTC, Atila Neves wrote:
So I tried using unit-threaded to run Phobos unit tests again
and had problems (which I'll look into later) with its
compile-time reflection. Then I realised I was an idiot since
I don't need to reflect on anything: all Phobos tests are in
unittest blocks so all I need to do is include them in the
build and unit-threaded will run them for me.
I tried a basic sanity check by running them in one thread
only with the -s option and got a segfault, and a failing test
before that. None of this should happen, and I'll be taking a
look at that as well.
But I carried on by removing the troublesome modules from the
build. These turned out to be:
std.datetime (fails)
std.process (fails and causes the segfault)
std.stdio (fails)
All the others pass in single threaded mode. After this I
tried using threads and std.parallelism failed, so I took that
away from the build as well.
Another thing to mention is that although the tests are
running in threads, since when I wrote the library the
getUnitTests __traits wasn't available (and since then I
wasn't interested in using it), each module's unit tests run
as one test. So they only interleave with other modules, not
with each other.
Running in one thread took 39 +/- 1 seconds.
Running in 8 threads took... ~41 seconds.
Oops. I noticed some tests take a lot longer so I tried
removing those. They were:
std.file
std.conv
std.regex
std.random
std.container
std.xml
std.utf
std.numeric
std.uuid
std.exception
I also removed any modules that were likely to be problematic
like std.concurrency and std.socket. With the reduced sample
size the results were:
1 thread: ~1.9s
8 threads: 4.1s +/- 0.2
So the whole threading thing isn't looking so great. Or at
least not how I implemented it. This got me thinking about my
own projects. The tests run so fast I never really paid
attention to how fast they were running. I compared running
the unit tests in Cerealed in one or more threads and got the
same result: running in one thread was faster.
I have to look to be sure but maybe the bottleneck is output.
As in actually printing the results to the screen. I had to
jump through a few hoops to make sure the output wasn't
interleaved, and in the end decided to have one thread be
responsible for that, with the tests sending it output
messages.
For reference, I copied all of the std/*.d modules into a
local std directory, compiled all of them with dmd -unittest
-c, then used this as the build command:
dmd -unittest -I~/coding/d/unit-threaded/source ut.d
std/algorithm.o std/array.o std/ascii.o std/base64.o
std/bigint.o std/bitmanip.o std/compiler.o std/complex.o
std/container.o std/cstream.o std/csv.o std/demangle.o
std/encoding.o std/format.o std/functional.o std/getopt.o
std/json.o std/math.o std/mathspecial.o std/metastrings.o
std/mmfile.o std/numeric.o std/outbuffer.o std/range.o
std/signals.o std/stdint.o std/stdiobase.o std/stream.o
std/string.o std/syserror.o std/system.o std/traits.o
std/typecons.o std/typelist.o std/typetuple.o std/uri.o
std/variant.o std/zip.o std/zlib.o libunit-threaded.a
-ofphobos_ut
I got libunit-threaded.a by running dub build in the root
directory of unit-threaded.
I might just implement a random order option now. Hmm.
Atila
Out of curiosity are you on Windows?
Re: Running Phobos unit tests in threads: I have data
On Saturday, 3 May 2014 at 12:24:59 UTC, Atila Neves wrote: Out of curiosity are you on Windows? No, Arch Linux 64-bit. I also just noticed a glaring threading bug in my code as well that somehow's never turned up. This is not a good day. Atila I'm surprised. Threads should be cheap on Linux. Something funky is definitely going on I bet.
GC vs Resource management.
I've been reading all the topics with those radical ideas about the GC and dtors and, honestly, i'd rather call them insane. After all the reading and thinking, i came to conclusion, that what Andrey suggests is to call dtors only on stack-allocated structs. That also implies, that one can't put those in containers and gc-allocated objects. Since all of them: containers, structs, classes -- are all first-class objects they must be all nicely combined in code, without any unintuitive stuff. I mean, really, let us look at c++ strings. There are const char*, std::sting, QString, Poco::String, icu::UnicodeString, and every big project uses it's own strings implementation that can't be used together in a sane way. That is what great in D: you just threw the idea of library-implemented strings away and made it not only standard, but special and that what makes it intuitive and simple (unless you interact with c++). Never seen any non-standart strings for D. The point is, that every library and every coder add to the project incompatible and difficult to use together stuff, so every programmer already has to think of all the problems with other's people code, and you just can't add same shit to the language. All elements must nicely interact together and otherwise it's a total disaster. Back to the dtors: i understand, that all the stuff you propose could make GC faster, simpler, and cooler, but it sounds insane to anyone, who uses the language, not develops it, that if you create struct object, dror will be called, but if you place the copy in a container, it wont. It's just unanderstandable from user's point of view. Now, for the solution. First, we can just fix this shit with arrays of structs and that's it. That still lives us with false pointers problem: not everything gets collected. That's no good. So, i propose to think of actually separating gc-memory management (via GC) and other resources management: via some new (or maybe old) mechanism. Let me start with listing of existing solutions: 1) C. That is the simplest way: fully-manual resource management. It's obvious, we can't do that in D, because it's supposed to be simpler for coding, than C. 2) Go. Actually, this one is not that different: it uses GC for memory only, and manual management for all the rest (with help of defer operator). We can't do it either, for the same reasons. 3) C++. This one is semi-automatic (talking about user code, not some allocator libraries): you choose the scheme (refcounting, unique reference) and then it'll do the rest. 4) Rust. I'm not a pro here, but as i understand, it uses C++ way, and adds gc-collected pointers, but not sure, so help me here. 5) Python. GC-only, except one clever case: with statement calls close() method. Please, if there are any pros in other platforms, add your knowledge to this list, i would very much love to learn (same, if a made any mistakes). Now, for D: obviously D has GC-managed heap. First, we should, like in Go, leave only managing gc-memory to the GC -- this is just rephrasing Andreys proposal. The simplest way o manage all other resources would be manual, Go-way: A a = A(); scope(exit) a.~A(); But it's to annoying, to that all the time, so we really want dtors to save us lost of typing and debugging, but they can't be called all the time, because we can put stuff in GC-collected objects. What i propose, is to include new concept in D: scoped objects. Any object (no matter is it a class or struct instance) can be either scoped or not. Dtors for scoped objects are called when out of scope, dtors for non-scoped objects are not called at all. It is actually as simple as rewrite code A a = A(); as A a = A(); scope(exit) a.~A(); For all a's, which are scoped objects. For me, it is both a simple concept and good rationalization for difficult dror-gets-called-or-not rules. That leaves only to determine, what objects are scoped. Well, that is obviously stack-allocated structs, gc-allocated scope classes and gc-allocated structs in scope classes. But that is just my idea. This post has so many words, because it's very important, that D devs make good decision on that deep problem, and the key to such decision is information and discussion. UPD: Also, about arrays and slices: if we could easily pass them around as cost ref-s, just like in C++, then we could make them value-types and they wouldn't require any ref counting. I would suggest, make all in function arguments const refs.
Re: GC vs Resource management.
On Saturday, 3 May 2014 at 12:28:03 UTC, monnoroch wrote: I've been reading all the topics with those radical ideas about the GC and dtors and, honestly, i'd rather call them insane. After all the reading and thinking, i came to conclusion, that what Andrey suggests is to call dtors only on stack-allocated structs. That also implies, that one can't put those in containers and gc-allocated objects. Since all of them: containers, structs, classes -- are all first-class objects they must be all nicely combined in code, without any unintuitive stuff. I mean, really, let us look at c++ strings. There are const char*, std::sting, QString, Poco::String, icu::UnicodeString, and every big project uses it's own strings implementation that can't be used together in a sane way. That is what great in D: you just threw the idea of library-implemented strings away and made it not only standard, but special and that what makes it intuitive and simple (unless you interact with c++). Never seen any non-standart strings for D. The point is, that every library and every coder add to the project incompatible and difficult to use together stuff, so every programmer already has to think of all the problems with other's people code, and you just can't add same shit to the language. All elements must nicely interact together and otherwise it's a total disaster. Back to the dtors: i understand, that all the stuff you propose could make GC faster, simpler, and cooler, but it sounds insane to anyone, who uses the language, not develops it, that if you create struct object, dror will be called, but if you place the copy in a container, it wont. It's just unanderstandable from user's point of view. +1 about dtors. Now, for the solution. First, we can just fix this shit with arrays of structs and that's it. That still lives us with false pointers problem: not everything gets collected. That's no good. So, i propose to think of actually separating gc-memory management (via GC) and other resources management: via some new (or maybe old) mechanism. Let me start with listing of existing solutions: 1) C. That is the simplest way: fully-manual resource management. It's obvious, we can't do that in D, because it's supposed to be simpler for coding, than C. 2) Go. Actually, this one is not that different: it uses GC for memory only, and manual management for all the rest (with help of defer operator). We can't do it either, for the same reasons. 3) C++. This one is semi-automatic (talking about user code, not some allocator libraries): you choose the scheme (refcounting, unique reference) and then it'll do the rest. 4) Rust. I'm not a pro here, but as i understand, it uses C++ way, and adds gc-collected pointers, but not sure, so help me here. 5) Python. GC-only, except one clever case: with statement calls close() method. Please, if there are any pros in other platforms, add your knowledge to this list, i would very much love to learn (same, if a made any mistakes). Now, for D: obviously D has GC-managed heap. First, we should, like in Go, leave only managing gc-memory to the GC -- this is just rephrasing Andreys proposal. The simplest way o manage all other resources would be manual, Go-way: A a = A(); scope(exit) a.~A(); But it's to annoying, to that all the time, so we really want dtors to save us lost of typing and debugging, but they can't be called all the time, because we can put stuff in GC-collected objects. What i propose, is to include new concept in D: scoped objects. Any object (no matter is it a class or struct instance) can be either scoped or not. Dtors for scoped objects are called when out of scope, dtors for non-scoped objects are not called at all. It is actually as simple as rewrite code A a = A(); as A a = A(); scope(exit) a.~A(); For all a's, which are scoped objects. For me, it is both a simple concept and good rationalization for difficult dror-gets-called-or-not rules. That leaves only to determine, what objects are scoped. Well, that is obviously stack-allocated structs, gc-allocated scope classes and gc-allocated structs in scope classes. But that is just my idea. This post has so many words, because it's very important, that D devs make good decision on that deep problem, and the key to such decision is information and discussion. UPD: Also, about arrays and slices: if we could easily pass them around as cost ref-s, just like in C++, then we could make them value-types and they wouldn't require any ref counting. I would suggest, make all in function arguments const refs. I like the idea of scoping dtor's. But I still want the ability to say: Hey I have this global variable, if I assign a value to it and later null it, it'll call its destructor if its not referenced anywhere else. Which in turn would make me think ref counting would be a good idea. But either way, I think we are getting ahead of ourselves
Re: GC vs Resource management.
Hey I have this global variable, if I assign a value to it and later null it, it'll call its destructor if its not referenced anywhere else. Which in turn would make me think ref counting would be a good idea. It seems, that ARC is the only way. There were idea to make all non-scoped (in my terminology) objects ARC-d, if they have dtors. That makes sense to me.
Re: GC vs Resource management.
Scoped-objects + ARC on non-scoped objects with dtors + GC on non-scoped objects w/o dtors would arguably solve the problem, especially, is arrays of scoped objects would be considered also scoped, or just add separate scoped arrays.
[OT] Slides from 2014 International Symposium on Code Generation and Optimization
Hi, the slides are now available, with lots of interesting talks about code generation, which are a domain of systems programming targeted by D. http://cgo.org/cgo2014/conference/program/ -- Paulo
Re: The Current Status of DQt
On Sat, 03 May 2014 11:00:37 + w0rp via Digitalmars-d digitalmars-d@puremagic.com wrote: So, I am eager to hear what people think about all of this. Does anyone like the work that I have done, and will it be useful? Have I committed some terrible crime against nature, for which I must be punished? Does anyone have any ideas about things that could be improved, or where to go next? Please, let me know. I can't really comment much on your approach or implementation, because I haven't looked at what you've done, and while I do have some experince with Qt, I haven't done a lot with it (and I haven't done a lot with GUI programming in general), so I'm not in a good position to comment on or review a D wrapper for Qt. That being said, if I were to write a GUI application in either C++ or D, I would want to use Qt (preferably Qt5). And given what is on my todo list, I expect that I'll be looking at writing a GUI application in D within a year or two. So, having a useable wrapper library for Qt in D is something that I'm very interested in seeing happen. I wasn't aware of your efforts in that regard (I was just aware of QtD, though it's not clear to me how actively developed it is at this point, since it was my understanding that the original devs dropped it, but I know that some folks have repos of it with more recent changes), but I'm very glad that someone is taking up this torch, and I wish you the best of luck with it. I'm just not likely to be of much help in reviewing or critiquing it at this point. However, there are quite a few folks around here who are not only much more familiar with GUI development but who are also very opinionated on the matter, so hopefully some of them will be able to chime in with useful insights. - Jonathan M Davis
Re: GC vs Resource management.
Am 03.05.2014 14:28, schrieb monnoroch: I've been reading all the topics with those radical ideas about the GC and dtors and, honestly, i'd rather call them insane. After all the reading and thinking, i came to conclusion, that what Andrey suggests is to call dtors only on stack-allocated structs. That also implies, that one can't put those in containers and gc-allocated objects. Since all of them: containers, structs, classes -- are all first-class objects they must be all nicely combined in code, without any unintuitive stuff. I mean, really, let us look at c++ strings. There are const char*, std::sting, QString, Poco::String, icu::UnicodeString, and every big project uses it's own strings implementation that can't be used together in a sane way. That is what great in D: you just threw the idea of library-implemented strings away and made it not only standard, but special and that what makes it intuitive and simple (unless you interact with c++). Never seen any non-standart strings for D. The point is, that every library and every coder add to the project incompatible and difficult to use together stuff, so every programmer already has to think of all the problems with other's people code, and you just can't add same shit to the language. All elements must nicely interact together and otherwise it's a total disaster. Back to the dtors: i understand, that all the stuff you propose could make GC faster, simpler, and cooler, but it sounds insane to anyone, who uses the language, not develops it, that if you create struct object, dror will be called, but if you place the copy in a container, it wont. It's just unanderstandable from user's point of view. Now, for the solution. First, we can just fix this shit with arrays of structs and that's it. That still lives us with false pointers problem: not everything gets collected. That's no good. So, i propose to think of actually separating gc-memory management (via GC) and other resources management: via some new (or maybe old) mechanism. Let me start with listing of existing solutions: 1) C. That is the simplest way: fully-manual resource management. It's obvious, we can't do that in D, because it's supposed to be simpler for coding, than C. 2) Go. Actually, this one is not that different: it uses GC for memory only, and manual management for all the rest (with help of defer operator). We can't do it either, for the same reasons. 3) C++. This one is semi-automatic (talking about user code, not some allocator libraries): you choose the scheme (refcounting, unique reference) and then it'll do the rest. 4) Rust. I'm not a pro here, but as i understand, it uses C++ way, and adds gc-collected pointers, but not sure, so help me here. 5) Python. GC-only, except one clever case: with statement calls close() method. Please, if there are any pros in other platforms, add your knowledge to this list, i would very much love to learn (same, if a made any mistakes). Now, for D: obviously D has GC-managed heap. First, we should, like in Go, leave only managing gc-memory to the GC -- this is just rephrasing Andreys proposal. The simplest way o manage all other resources would be manual, Go-way: A a = A(); scope(exit) a.~A(); But it's to annoying, to that all the time, so we really want dtors to save us lost of typing and debugging, but they can't be called all the time, because we can put stuff in GC-collected objects. What i propose, is to include new concept in D: scoped objects. Any object (no matter is it a class or struct instance) can be either scoped or not. Dtors for scoped objects are called when out of scope, dtors for non-scoped objects are not called at all. It is actually as simple as rewrite code A a = A(); as A a = A(); scope(exit) a.~A(); For all a's, which are scoped objects. For me, it is both a simple concept and good rationalization for difficult dror-gets-called-or-not rules. That leaves only to determine, what objects are scoped. Well, that is obviously stack-allocated structs, gc-allocated scope classes and gc-allocated structs in scope classes. But that is just my idea. This post has so many words, because it's very important, that D devs make good decision on that deep problem, and the key to such decision is information and discussion. UPD: Also, about arrays and slices: if we could easily pass them around as cost ref-s, just like in C++, then we could make them value-types and they wouldn't require any ref counting. I would suggest, make all in function arguments const refs. C# and Java also have scoped blocks (using, try-with-resources), similar to Python for resource management. Ada has controlled types for it, where Finalize() plays the role of C++ destructor. Additionally all languages with lambda support do offer resource management via implicit control structures. Mostly visible in Lisp and ML dialects. Great in the languages that allow the lambda as last parameter to appear outside of the call.
Re: GC vs Resource management.
On Saturday, 3 May 2014 at 13:21:04 UTC, Paulo Pinto wrote: C# and Java also have scoped blocks (using, try-with-resources), similar to Python for resource management. Yeah, but it doesn't work for graphs that maintain resources, such as a scene graph which hold onto texture memory. Unfortunately, you don't want GC collection to release it either. I think in most cases resources can either be handled by owned pointers or a regional GC (in this case a GC that only trace SceneNodePointers).
Re: GC vs Resource management.
Am 03.05.2014 16:02, schrieb Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com:
On Saturday, 3 May 2014 at 13:21:04 UTC, Paulo Pinto wrote:
C# and Java also have scoped blocks (using, try-with-resources),
similar to Python for resource management.
Yeah, but it doesn't work for graphs that maintain resources, such as a
scene graph which hold onto texture memory. Unfortunately, you don't
want GC collection to release it either.
I think in most cases resources can either be handled by owned pointers
or a regional GC (in this case a GC that only trace SceneNodePointers).
Why not?
- Make all scene graph nodes IDisposable.
- Have a using(rootNode) {} on your render loop
--
Paulo
Re: GC vs Resource management.
On Saturday, 3 May 2014 at 14:31:59 UTC, Paulo Pinto wrote:
- Make all scene graph nodes IDisposable.
- Have a using(rootNode) {} on your render loop
That would work for a static scene.
But you want to mark resources ready for release when nodes are
removed from the graph dynamically. In most cases shared pointers
(ref counting) would work, but if you allow fractal recursion
then you will get cycles. (e.g.
meshnode-scaleRND-rotateRND-stopIfTooSmall-meshnode )
Re: GC vs Resource management.
Am 03.05.2014 16:43, schrieb Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com:
On Saturday, 3 May 2014 at 14:31:59 UTC, Paulo Pinto wrote:
- Make all scene graph nodes IDisposable.
- Have a using(rootNode) {} on your render loop
That would work for a static scene.
But you want to mark resources ready for release when nodes are removed
from the graph dynamically. In most cases shared pointers (ref counting)
would work, but if you allow fractal recursion then you will get
cycles. (e.g. meshnode-scaleRND-rotateRND-stopIfTooSmall-meshnode )
Easy, you already know that you don't need the node, just call the
dispose method, instead of marking for release.
Cannot release right away? Place them in a to be removed queue and do
the cleaning in a specific controlled point.
--
Paulo
Re: GC vs Resource management.
On Saturday, 3 May 2014 at 15:10:43 UTC, Paulo Pinto wrote: Easy, you already know that you don't need the node, just call the dispose method, instead of marking for release. But you don't know unless you use RC or GC. Let's say you make a jungle. Lots of pointers to the tree root node. And you also don't want to wait with collection if you hold onto hardware resources (forcing perhaps lower resolution graphics if you are low on GPU resources).
Re: The Current Status of DQt
On Sat, 2014-05-03 at 11:00 +, w0rp via Digitalmars-d wrote: […] 2. I have not yet implemented signals and slots. Two options for this involve generating QMetaObject instances for classes, possibly via template mixins, which do what 'moc' does for C++. A second option is to use Qt5 for the library and to force all signals and slots behaviour to go through functions, as Qt5 can use function pointers as slots. (I prefer option 2.) It's Qt, signals and slots are necessary! From a personal perspective I only care about Qt5 and in particular QML. So, I am eager to hear what people think about all of this. Does anyone like the work that I have done, and will it be useful? Have I committed some terrible crime against nature, for which I must be punished? Does anyone have any ideas about things that could be improved, or where to go next? Please, let me know. Whilst GtkD works and I am using it for a small GNOME-based project, Qt is a better choice for systems that are to work on GNOME, OSX, KDE, Android, and even Windows. QtD appears to have died, though Michael Crompton has been trying to get it going again: https://bitbucket.org/michaelc37/qtd-experimental My progress has been somewhat slow in writing all of this, as I have been writing it mostly in the evenings, moslty during weekdays, after my day job. I've also been running into problems for which there are no easy answers, possibly no documentation for, and so on. So a great deal of my time has been spent more on thinking of what to do next, rather than writing anything. (It took me possibly months to come up with the resource management scheme that I have now.) I suspect there is a chicken and egg situation here: D doesn't have a strong Qt offering, so people do not use D for Qt work, and no-one is using Qt and D so there is no resource to ensure a strong Qt offering for D. This cycle got broken for Go when Gustavo Niemeyer decided his group in Canonical would use Go and QML and so he created the Go support for QML on company time. He has focussed entirely on support for QML, and not worried about providing a complete Go binding to Qt. Much of it is there, but only with a view to supporting the QML aspects of things. This has meant that Go+QML is really rather good. I wonder if instead of trying to create a D binding to Qt, DQt (or QtD), following Gustavo's approach with Go and just providing a D binding to QML would get further faster. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Running Phobos unit tests in threads: I have data
Ok, so I went and added __traits(getUnitTests) to unit-threaded. That way each unittest block is its own test case. I registered these modules in std to run: array, ascii, base64, bigint, bitmanip, concurrency, container, cstream. On the good news front, they all passed even though they were running concurrently. On the bad news front, single-threaded operation was still faster (0.22s vs 0.28s). I still don't know why. I fixed my concurrency bug, now I'm using taskPool.amap. Atila
Re: GC vs Resource management.
Am 03.05.2014 17:20, schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com: On Saturday, 3 May 2014 at 15:10:43 UTC, Paulo Pinto wrote: Easy, you already know that you don't need the node, just call the dispose method, instead of marking for release. But you don't know unless you use RC or GC. I am always speaking from the point of view of automatic memory management, be it RC, GC or compiler aided dataflow analysis. Let's say you make a jungle. Lots of pointers to the tree root node. And you also don't want to wait with collection if you hold onto hardware resources (forcing perhaps lower resolution graphics if you are low on GPU resources). If you mean you need to be sure that all references are gone from the graph, before doing a dispose() invocation, then yeah you need some form of RC, even with a GC. However that doesn't mean that the developer/API client needs to care about it. It is a matter of how the graph node construction is exposed to the clients. With proper a proper ADT that can be hidden from the API client. Automatic resource management requires another type of thinking anyway. -- Paulo
Re: Running Phobos unit tests in threads: I have data
I can reproduce the slower-with-threads issue without using my
library. I've included the source file below and would like to
know if other people see the same thing.
The Phobos modules are all called ustd because I
couldn't/didn't know how to get this to work otherwise. So I
copied the std/*.d files to a directory called ustd and changed
their module declarations. Silly but it works. I'd love to know
how to do this properly.
With this file, I consistenly get faster times with -s (for
single-threaded) than without (multi-threaded):
import std.parallelism;
import std.getopt;
import ustd.array;
import ustd.ascii;
import ustd.base64;
import ustd.bigint;
import ustd.bitmanip;
import ustd.concurrency;
import ustd.container;
import ustd.cstream;
alias TestFunction = void function();
auto getTests(Modules...)() {
TestFunction[] tests;
foreach(mod; Modules) {
foreach(test; __traits(getUnitTests, mod)) {
tests ~= test;
}
}
return tests;
}
void main(string[] args) {
bool single;
getopt(args,
single|s, single
);
enum tests = getTests!(
ustd.array,
ustd.ascii,
ustd.base64,
ustd.bigint,
ustd.bitmanip,
ustd.concurrency,
ustd.container,
ustd.cstream,
);
if(single) {
foreach(test; tests) {
test();
}
} else {
foreach(test; tests.parallel) {
test();
}
}
}
Re: More radical ideas about gc and reference counting
On 5/3/14, 1:49 AM, Benjamin Thaut wrote: 2) Quit D. (which is becomeing more and more an option when reading the recent news group discussions.) The entire idea of starting these discussions is to gather a sense of shared vision with the community on the best direction to follow. I'm trying to steer things so as to gain the maximum benefit from each potential breakage. In wake of that, it seems incongruous that first you ask for even larger breaking changes to the language, but then consider quitting it entirely on account of changes being too disruptive. Anyhow, just to clarify, it seems like eliminating destructor calls during GC is not a viable option. I'll define std.allocator to allow users to define such a GC if they so want, without prescribing either policy. Andrei
Re: Running Phobos unit tests in threads: I have data
On 5/3/14, 4:54 AM, Atila Neves wrote: So I tried using unit-threaded to run Phobos unit tests [snip] Thanks. Are you using thread pooling (a limited number of threads e.g. 1.5 * cores running all unittests)? -- Andrei
Re: Running Phobos unit tests in threads: I have data
On 5/3/2014 5:26 AM, Rikki Cattermole wrote: Something funky is definitely going on I bet. No doubt: http://www.youtube.com/watch?v=aZcbDESaxhY
Re: Running Phobos unit tests in threads: I have data
On 5/3/2014 10:22 AM, Atila Neves wrote: I can reproduce the slower-with-threads issue without using my library. I've included the source file below and would like to know if other people see the same thing. I haven't investigated this, but my suspicions are: 1. thread creation/destruction is dominating the times. 2. since very few of the unittests block, there is no speed advantage from having more threads than cores. If you limit the number of threads to the number of cores on your machine, you might see a speedup.
Re: GC vs Resource management.
On 5/3/14, 5:39 AM, monnoroch wrote: Hey I have this global variable, if I assign a value to it and later null it, it'll call its destructor if its not referenced anywhere else. Which in turn would make me think ref counting would be a good idea. It seems, that ARC is the only way. There were idea to make all non-scoped (in my terminology) objects ARC-d, if they have dtors. That makes sense to me. Interesting, we haven't explored that. The most problematic implication would be that classes with destructors will form a hierarchy separate from Object. Andrei
Re: GC vs Resource management.
On Saturday, 3 May 2014 at 18:27:46 UTC, Andrei Alexandrescu wrote: On 5/3/14, 5:39 AM, monnoroch wrote: Hey I have this global variable, if I assign a value to it and later null it, it'll call its destructor if its not referenced anywhere else. Which in turn would make me think ref counting would be a good idea. It seems, that ARC is the only way. There were idea to make all non-scoped (in my terminology) objects ARC-d, if they have dtors. That makes sense to me. Interesting, we haven't explored that. The most problematic implication would be that classes with destructors will form a hierarchy separate from Object. Andrei Yeah, that's a good point: How do you define a class with/without destructor, when they all derive from Object anyways. Necessarily, Object needs to have a destructor (even if it does nothing) for any other sub-class to have them. Or vice versa, if Object has no destructor, no subclass can have them? So is it even possible to separate classes into two different groups?
Re: More radical ideas about gc and reference counting
On Sat, May 03, 2014 at 11:12:36AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: [...] Anyhow, just to clarify, it seems like eliminating destructor calls during GC is not a viable option. I'll define std.allocator to allow users to define such a GC if they so want, without prescribing either policy. [...] Thank you. ;-) On that note, it would be very nice if we could clearly define when dtor calls will / will not happen. As someone else said, to an end-user of D it is hard to accept that basic language constructs like arrays and dtors, when used together, fail to function in an expected way (without understanding what goes on underneath the hood, e.g. why dtors of array elements may not get called). Ideally, the language should be designed such that these obvious combinations of language constructs should either Just Work(tm), or not be allowed, or require explicit annotation (so that the user knows something unexpected might happen). But, since we're not in an ideal world, the very least we could do is to clearly define exactly which combinations of language constructs may behave in an unexpected way, and document them up front in a prominent place. Otherwise, we risk turning off potential users -- I can just imagine a newbie to D writing something like File[] files; and then wondering why things don't work as expected, and then throwing in the towel and say what a lousy language, let me move on to another one. And on that note, I'd like to say that my previous posts about prohibiting structs with dtors as class members (if we were to move in the direction of getting rid of class dtors altogether, which happily isn't the case anymore) were primarily motivated by the desire to see more of D obeying the principle of least surprise: two built-in language constructs, structs with dtors and class members, when combined together, *should* Just Work -- one expects that dtors will get called with the struct goes out of scope, by the very definition of a dtor, so one would expect they will still get cleaned up when they happen to be a class member. The fact that they don't is a surprise, which then requires some other way of warning the user that things aren't what they might be expected to be. Maybe my proposed solutions suck, but the underlying problem still needs to be addressed. The scope of the problem is smaller, now that we're no longer killing off class dtors, but nevertheless something needs to be done about it. I think this is one area where D could use a lot of improvement. There are currently a handful of glaring holes where built-in language constructs interact with each other in unexpected or buggy ways. While it may feel like mole-whacking (because of combinatorial explosion as you add features to the language), I think it's very important to address, since otherwise it gives new users an impression (not necessarily well-founded, but first impressions do matter) of sloppy language design. The seams show through, and it's not very nice. One example is the interaction of dtors with the GC. Another example is the interaction of const/immutable with AA's. Another is the interaction of @disabled with .init and other generic code. It seems that almost every non-trivial use of these features is like navigating a minefield -- there are so many gotchas, unexpected behaviours, and implementation bugs, that it's embarrassing. Other areas include shared, though I don't have first-hand experience of that so I can't speak for it. While proposing radical changes may be exhilarating, in the long run that may do more harm than good. What these features need is some TLC and detailed fine-tuning within the current, already-existing framework. TL;DR: I'd like to see more attention paid to the details of how language features interact with each other, and fixing those issues, rather than inventing more radical new ideas that may or may not solve the problem, and more likely than not will introduce new problems to add to our already-long list of issues. T -- Amateurs built the Ark; professionals built the Titanic.
Re: D For A Web Developer
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote: One good example is networking tests - if I worked on an airplane I'd love to not test tests that need connectivity with a simple regex. I am suspicious that testing networks with a unit test is an inappropriate use of unit tests. Unit tests should be testing individual functions. The network for those tests should be a mockup, not the actual network. A mock network: 1. can model extreme, unusual, perverse, and corner cases of networks, whereas real networks try to avoid that 2. will generate reproducible results Testing networks should be more of a system test, not a unit test.
Re: Running Phobos unit tests in threads: I have data
On Saturday, 3 May 2014 at 18:26:37 UTC, Walter Bright wrote: On 5/3/2014 10:22 AM, Atila Neves wrote: I can reproduce the slower-with-threads issue without using my library. I've included the source file below and would like to know if other people see the same thing. I haven't investigated this, but my suspicions are: 1. thread creation/destruction is dominating the times. In the current measurements probably since the whole run takes less than a second. But the first ones I did were dozens of seconds long, so I don't think so. 2. since very few of the unittests block, there is no speed advantage from having more threads than cores. If you limit the number of threads to the number of cores on your machine, you might see a speedup. Like I mentioned above, unless I'm mistaken taskPool should be using a correct number of threads for my machine already.
Re: Running Phobos unit tests in threads: I have data
On Saturday, 3 May 2014 at 18:16:52 UTC, Andrei Alexandrescu wrote: On 5/3/14, 4:54 AM, Atila Neves wrote: So I tried using unit-threaded to run Phobos unit tests [snip] Thanks. Are you using thread pooling (a limited number of threads e.g. 1.5 * cores running all unittests)? -- Andrei I'm using parallel and taskPool from std.parallelism. I was under the impression it gave me a ready-to-use pool with as many threads as I have cores.
Re: More radical ideas about gc and reference counting
On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote: If a class has at least one member with a destructor, the compiler might need to generate a destructor for the class. And in fact that's what dmd does.
Re: Progress on Adam Wilson's Graphics API?
On Sat, 03 May 2014 02:56:37 -0700, Nordlöw per.nord...@gmail.com wrote: Is there any progress on the graphics API Adam Wilson is working on? Yes. There has been progress. I am currently finishing up the DirectX 11 bindings. For now it will include everything but 3D. I am focusing on Windows 2D for the moment because that is the environment I am most familiar with. If you want to help with OpenGL for Linux or OSX, I will gladly pull requests! I'll have much more to say about Aurora at DConf. However, I am dealing with a work emergency all weekend. I'll be starting to build out the immediate mode layer sometime later this week. You can follow all progress on GitHub here: https://github.com/auroragraphics/ -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: D For A Web Developer
On Thursday, 1 May 2014 at 10:50:12 UTC, John Colvin wrote: On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote: On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote: On 2014-04-30 11:43, Dicebot wrote: This is common complaint I still fail to understand. I have never ever wanted to run a single unit test, why would one need it? If running all module tests at once creates problems than either module is too big or unit tests are not really unit tests. Why would I run more tests than I have to? Because you hardly notice difference between 0.1 and 0.5 seconds The compilation time is often more of a problem than the runtime. For me it's the output. I don't want to see the output of other tests when I'm debugging a failure. Atila
Re: D For A Web Developer
On Thursday, 1 May 2014 at 09:58:32 UTC, Jacob Carlborg wrote: On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote: This cannot be a good idea. If the block says unittest then it contains unit tests, not integration tests or system tests, just unit tests. Then we need to come up with a separate framework for doing all other kinds of tests. This is why I started to learn Cucumber. Atila
Re: Running Phobos unit tests in threads: I have data
03-May-2014 21:22, Atila Neves пишет:
I can reproduce the slower-with-threads issue without using my library.
I've included the source file below and would like to know if other
people see the same thing.
The Phobos modules are all called ustd because I couldn't/didn't know
how to get this to work otherwise. So I copied the std/*.d files to a
directory called ustd and changed their module declarations. Silly but
it works. I'd love to know how to do this properly.
[snip]
if(single) {
foreach(test; tests) {
test();
}
} else {
foreach(test; tests.parallel) {
Try different batch size:
test.parallel(1), test.parallel(2) etc.
--
Dmitry Olshansky
Re: GC vs Resource management.
Interesting, we haven't explored that. The most problematic implication would be that classes with destructors will form a hierarchy separate from Object. As i understood, you want to remove dtors for non-scoped objects completely, so all classes will be without it, except user defined ones. Can we mark all dtors virtual by default, so there wouldn't need to be dtor in object?
Re: GC vs Resource management.
The most problematic implication would be that classes with destructors will form a hierarchy separate from Object. What for? As i understand object's dtor does nothing, so for any class we can determine, if dtor is empty. I don't see a problem here. Cycles and locks for RC are the biggest problems, if you ask me. Also, what about arrays and maps?
Re: Running Phobos unit tests in threads: I have data
if(single) {
foreach(test; tests) {
test();
}
} else {
foreach(test; tests.parallel) {
Try different batch size:
test.parallel(1), test.parallel(2) etc.
So as to not have thread creation be disproportionately
represented, I repeated the module list over and over again,
making the number of tests run equal to 9990. This takes 5s on my
machine to run in on thread and 12s in multiple. Here are the
things I tried:
1. Created my own TaskPool so I could decide how many threads to
use
2. Changed the batch size in parallel from 1 to 10 to 100 to 1000
3. Explicitly spawn two threads and tell each to do a foreach on
half of the tests
None of them made it go any faster. I had similar results using
unit-threaded on my own projects. This is weird.
Atila
Re: Running Phobos unit tests in threads: I have data
gdc gave _very_ different results. I had to use different modules
because at some point tests started failing, but with gdc the
threaded version runs ~3x faster.
On my own unit-threaded benchmarks, running the UTs for Cerealed
over and over again was only slightly slower with threads than
without. With dmd the threaded version was nearly 3x slower.
Atila
On Saturday, 3 May 2014 at 21:14:29 UTC, Atila Neves wrote:
if(single) {
foreach(test; tests) {
test();
}
} else {
foreach(test; tests.parallel) {
Try different batch size:
test.parallel(1), test.parallel(2) etc.
So as to not have thread creation be disproportionately
represented, I repeated the module list over and over again,
making the number of tests run equal to 9990. This takes 5s on
my machine to run in on thread and 12s in multiple. Here are
the things I tried:
1. Created my own TaskPool so I could decide how many threads
to use
2. Changed the batch size in parallel from 1 to 10 to 100 to
1000
3. Explicitly spawn two threads and tell each to do a foreach
on half of the tests
None of them made it go any faster. I had similar results using
unit-threaded on my own projects. This is weird.
Atila
Re: GC vs Resource management.
On 2014-05-03 18:27:47 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Interesting, we haven't explored that. The most problematic implication would be that classes with destructors will form a hierarchy separate from Object. Seems like people have been ignoring my two posts in the thread radical ideas about gc and reference counting. I've been proposing exactly that, and there's a way if you don't want a separate class hierarchy. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Running Phobos unit tests in threads: I have data
Same thing with unit_threaded on Phobos, 3x faster even without
repeating the modules (0.1s vs 0.3s). Since the example is
shorter than the other one, I'll post it here in case anyone else
wants to try:
import unit_threaded.runner;
int main(string[] args) {
return args.runTests!(
ustd.array,
ustd.ascii,
ustd.base64,
ustd.bigint,
ustd.bitmanip,
ustd.concurrency,
ustd.container,
ustd.cstream,
);
}
On Saturday, 3 May 2014 at 21:42:13 UTC, Atila Neves wrote:
gdc gave _very_ different results. I had to use different
modules because at some point tests started failing, but with
gdc the threaded version runs ~3x faster.
On my own unit-threaded benchmarks, running the UTs for
Cerealed over and over again was only slightly slower with
threads than without. With dmd the threaded version was nearly
3x slower.
Atila
On Saturday, 3 May 2014 at 21:14:29 UTC, Atila Neves wrote:
if(single) {
foreach(test; tests) {
test();
}
} else {
foreach(test; tests.parallel) {
Try different batch size:
test.parallel(1), test.parallel(2) etc.
So as to not have thread creation be disproportionately
represented, I repeated the module list over and over again,
making the number of tests run equal to 9990. This takes 5s on
my machine to run in on thread and 12s in multiple. Here are
the things I tried:
1. Created my own TaskPool so I could decide how many threads
to use
2. Changed the batch size in parallel from 1 to 10 to 100 to
1000
3. Explicitly spawn two threads and tell each to do a foreach
on half of the tests
None of them made it go any faster. I had similar results
using unit-threaded on my own projects. This is weird.
Atila
Re: Progress on Adam Wilson's Graphics API?
You can follow all progress on GitHub here: https://github.com/auroragraphics/ Ok. Now I know :) Thx.
Re: More radical ideas about gc and reference counting
On 5/3/14, 12:40 PM, Walter Bright wrote:
On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
If a class has at least one member with a
destructor, the compiler might need to generate a destructor for the
class.
And in fact that's what dmd does.
Which suggests a simple solution for calling destructors for structs and
arrays:
* Lower new for structs to return:
new S;
-
return (new class { S member; }).member;
* Lower array construction similarly.
Then voila, the anonymous classes will destroy structs and arrays
appropriately.
Andrei
Re: Running Phobos unit tests in threads: I have data
On 5/3/14, 2:42 PM, Atila Neves wrote: gdc gave _very_ different results. I had to use different modules because at some point tests started failing, but with gdc the threaded version runs ~3x faster. On my own unit-threaded benchmarks, running the UTs for Cerealed over and over again was only slightly slower with threads than without. With dmd the threaded version was nearly 3x slower. Sounds like a severe bug in dmd or dependents. -- Andrei
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 3 May 2014 at 19:45:38 UTC, Adam Wilson wrote: Yes. There has been progress. I am currently finishing up the DirectX 11 bindings. For now it will include everything but 3D. I am focusing on Windows 2D for the moment because that is the environment I am most familiar with. Just a word of advice, don't make a big distinction between 2d and 3d. If anything, it should be matrix based, at that point the difference between 2d and 3d is just a different view matrix. This is how most modern hardware accelerated graphics works today. It is fine to have helper functions to do 2d specific tasks later on, but they should be fairly thin.
Re: std.allocator: false pointers
On Friday, 2 May 2014 at 17:15:20 UTC, Orvid King via Digitalmars-d wrote: Well, in a 64-bit address space, the false pointer issue is almost mute, the issue comes in when you try to apply this design to 32-bit, where the false pointer issue is more prevelent. Is the volume of memory saved by this really worth it? False pointers don't only cause memory consumption, you're forgetting that the GC will repeatedly scan memory held by false pointers at each collection*. This adds time to each collection and further increases the risk of other false pointers. False pointers can make many reasonable looking D programs behave unexpectedly when run in a 32-bit environment (to the point that I consider that they can break programs.) I think false pointers must be addressed to make claims that D is well-behaved on 32-bit systems. * Unless it is marked NO_SCAN of course, but this is not likely the common case.
Re: The Current Status of DQt
I'm intersting for DQt is better than QML.
Re: The Current Status of DQt
I think Get experience from QML to create a D binding to Qt, that is better than binding to QML. the Go's The programming thinking is not same to the C++,and D. DQt is Working hard more, but has significant effect for D. DQt is very clear.
Re: D For A Web Developer
On 5/3/2014 3:32 PM, Walter Bright wrote:
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
One good example is networking tests - if I worked on an airplane I'd
love to
not test tests that need connectivity with a simple regex.
I am suspicious that testing networks with a unit test is an
inappropriate use of unit tests.
Unit tests should be testing individual functions. The network for
those tests should be a mockup, not the actual network. A mock network:
1. can model extreme, unusual, perverse, and corner cases of networks,
whereas real networks try to avoid that
2. will generate reproducible results
Testing networks should be more of a system test, not a unit test.
I'm not sure mock networks can really be used for testing a client-only
lib of some specific protocol. There may also be other examples.
There's also the question of whether or not D's unittest {...} should
*expect* to be limited to tests that are *technically* unit tests.
Currently, unittest {...} is useful for more forms of testing than
just unit tests. I think it's debatable whether we want kill off those
uses without offering a comparable alternative with reasonable migration.
isUniformRNG
In std.random, is the isUniformRNG intended to determine whether the given type is *some* RNG or just a *specific* form of RNG? Because I don't see any isRNG that's more general. More importantly, should a crypto RNG count as isUniformRNG?
Re: D For A Web Developer
On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
I'm not sure mock networks can really be used for testing a client-only lib of
some specific protocol. There may also be other examples.
There's also the question of whether or not D's unittest {...} should *expect*
to be limited to tests that are *technically* unit tests. Currently, unittest
{...} is useful for more forms of testing than just unit tests. I think it's
debatable whether we want kill off those uses without offering a comparable
alternative with reasonable migration.
I'm not suggesting killing off anything. I'm suggesting it may not be good
practice to use unit tests for testing actual networks.
Re: More radical ideas about gc and reference counting
On 5/3/2014 6:44 PM, Andrei Alexandrescu wrote:
On 5/3/14, 12:40 PM, Walter Bright wrote:
On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
If a class has at least one member with a
destructor, the compiler might need to generate a destructor for the
class.
And in fact that's what dmd does.
Which suggests a simple solution for calling destructors for structs and
arrays:
* Lower new for structs to return:
new S;
-
return (new class { S member; }).member;
* Lower array construction similarly.
Then voila, the anonymous classes will destroy structs and arrays
appropriately.
Uhh, but doesn't this completely break as soon as class dtors go away?
Re: More radical ideas about gc and reference counting
On Sat, 03 May 2014 22:44:39 -0400
Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 5/3/2014 6:44 PM, Andrei Alexandrescu wrote:
On 5/3/14, 12:40 PM, Walter Bright wrote:
On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
If a class has at least one member with a
destructor, the compiler might need to generate a destructor for
the class.
And in fact that's what dmd does.
Which suggests a simple solution for calling destructors for
structs and arrays:
* Lower new for structs to return:
new S;
-
return (new class { S member; }).member;
* Lower array construction similarly.
Then voila, the anonymous classes will destroy structs and arrays
appropriately.
Uhh, but doesn't this completely break as soon as class dtors go away?
Based on other comments, I think that Andrei has been convinced that class
destructors can't go away at this point and that there certainly isn't any
consensus that it would even be desirable for them to go away (though what
he'd choose to do if we could break code willy-nilly, I don't know). So,
this particular proposal is presumably done with the idea that class
destructors are here to stay. Rather, it's trying to make it so that the
destructors for structs on the heap get run unlike now - which is a much
better direction to try and go IMHO.
- Jonathan M Davis
Re: More radical ideas about gc and reference counting
On Sat, May 3, 2014 at 3:49 AM, Benjamin Thaut via Digitalmars-d digitalmars-d@puremagic.com wrote: 2) Quit D. (which is becomeing more and more an option when reading the recent news group discussions.) -- Kind Regards Benjamin Thaut I never thought I would say this, but I have begun to move away from D. I know others who are doing the same. The advantages D has over other languages are slowly diminishing. Plus, as it is, D is just as complex and complicated as C++, if not more. Couple that with the never-ending bugs and weak development process, there isn't much confidence in choosing D. One of the main and crippling issues D has is its development process. Its inner circle, mainly Walter, Andrei and a few others, do not seem to have a good understanding of FOSS development process. For example, Rust is only a few years old and much younger than D, but it has a greater number of contributors, and its rate of contributors seems to be growing faster. D has failed at recruitment; I always read people (mainly the inner circle) mention the everlasting low-hanging fruits. Well, if the number of contributors was growing then the number of low-hanging fruits would be decreasing. Andrei recently introduced the bounty system, which not only is an insult to those who contribute to FOSS, but it also goes to show that he really doesn't understand how and why people contribute to FOSS without ever asking to be compensated. Last but not least, currently there are two main ways for new features to make it into D/Phobos: you either have to belong to the inner circle, or have to represent some corporation that's doing something with D. I don't remember seeing a feature that was added to D/Phobos with some on/off switch that people could try in the next release, and then send in feedback. You're in a much better position to make a decision about a feature if the users have actually used it and reported feedback. Ahh, and don't get me started on Phobos review process; it's a joke, it's bogus and just pathetic. If D had a sound development process, I don't think we would be having the problems that we have today.
Re: More radical ideas about gc and reference counting
On Sat, 03 May 2014 15:44:03 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 5/3/14, 12:40 PM, Walter Bright wrote:
On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
If a class has at least one member with a
destructor, the compiler might need to generate a destructor for
the class.
And in fact that's what dmd does.
Which suggests a simple solution for calling destructors for structs
and arrays:
* Lower new for structs to return:
new S;
-
return (new class { S member; }).member;
* Lower array construction similarly.
Then voila, the anonymous classes will destroy structs and arrays
appropriately.
This might be a good approach, though I confess that it strikes me as rather
weird to wrap structs in classes like that. It also leaves open the question
of how to deal with structs that are newed directly rather than put in an
array. _Those_ really need to be destroyed properly as well. And unless
you're suggesting that S* effectively become a pointer to a struct within
an anonymous class in all cases, not only would this not work for structs
which were newed up directly on the heap, but I'd be worried about what would
happen when someone did something like arr[5] with an array of structs. Would
they get a pointer to a class or a struct?
It was my understanding that some of what Rainer Schutze did with his precise
GC involved adding RTInfo which could make it possible to run struct
destructors for structs that were newed up directly on the heap. If that is
indeed the case, then I would think that we could use that for arrays of
structs as well.
- Jonathan M Davis
Re: D For A Web Developer
On Sat, 03 May 2014 19:36:53 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
I'm not sure mock networks can really be used for testing a
client-only lib of some specific protocol. There may also be other
examples.
There's also the question of whether or not D's unittest {...}
should *expect* to be limited to tests that are *technically* unit
tests. Currently, unittest {...} is useful for more forms of
testing than just unit tests. I think it's debatable whether we
want kill off those uses without offering a comparable alternative
with reasonable migration.
I'm not suggesting killing off anything. I'm suggesting it may not be
good practice to use unit tests for testing actual networks.
I'd write unit tests which talked to sockets on the same computer if that
was what was required to test a particular function, but I would definitely
consider it bad practice to have a unit test try to talk to anything on a
separate computer. Now, if you're using unittest blocks for something other
than unit tests, then I guess that that could be fine, though I question that
it's good practice to use unittest blocks for other purposes.
Regardless, unittest blocks don't really put any restrictions on what kind of
code can go in them, and I'd prefer that that stay the case. The discussion
on parallelizing unit tests threatens that on some level, but as long as we
have the means to mark unittest blocks in some manner that tells the test
runner not to run them in parallel with any other unittest blocks, then I
think that we should be fine on that front.
- Jonathan M Davis
Re: More radical ideas about gc and reference counting
On 5/3/14, 8:48 PM, Caligo via Digitalmars-d wrote: On Sat, May 3, 2014 at 3:49 AM, Benjamin Thaut via Digitalmars-d digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote: 2) Quit D. (which is becomeing more and more an option when reading the recent news group discussions.) -- Kind Regards Benjamin Thaut I never thought I would say this, but I have begun to move away from D. I know others who are doing the same. The advantages D has over other languages are slowly diminishing. Plus, as it is, D is just as complex and complicated as C++, if not more. Couple that with the never-ending bugs and weak development process, there isn't much confidence in choosing D. One of the main and crippling issues D has is its development process. Its inner circle, mainly Walter, Andrei and a few others, do not seem to have a good understanding of FOSS development process. For example, Rust is only a few years old and much younger than D, but it has a greater number of contributors, and its rate of contributors seems to be growing faster. D has failed at recruitment; I always read people (mainly the inner circle) mention the everlasting low-hanging fruits. Well, if the number of contributors was growing then the number of low-hanging fruits would be decreasing. Andrei recently introduced the bounty system, which not only is an insult to those who contribute to FOSS, but it also goes to show that he really doesn't understand how and why people contribute to FOSS without ever asking to be compensated. Mostly good points, but the bountysource program is an experiment by Facebook, not by myself. And (without me trying to speak on Facebook's behalf) it would be difficult to argue that Facebook doesn't understand FOSS or is out there to insult contributors. We're just experimenting with various angles. Last but not least, currently there are two main ways for new features to make it into D/Phobos: you either have to belong to the inner circle, or have to represent some corporation that's doing something with D. I don't remember seeing a feature that was added to D/Phobos with some on/off switch that people could try in the next release, and then send in feedback. You're in a much better position to make a decision about a feature if the users have actually used it and reported feedback. The on/off switch may be a nice idea in the abstract but is hardly the perfect recipe to good language feature development; otherwise everybody would be using it, and there's not overwhelming evidence to that. (I do know it's been done a few times, such as the (in)famous new scoping rule of the for statement for C++ which has been introduced as an option by VC++.) I wonder how you've gotten the perception that one needs to be a member of the inner circle mafia to get things into D. Today's major contributors to D came from all over, without any preexisting relationship to anyone else, and their admission ticket has been getting work done. Could you please get into detail on how you view things? (I tried to look over your past posts to see a pattern of rejected contributions, but didn't find such.) Ahh, and don't get me started on Phobos review process; it's a joke, it's bogus and just pathetic. Actually I'd love to get you started so I'd understand your angle better. I'm sure we can do a lot better. One good thing Phobos reviews have done since we initiated them has been to prevent bad artifacts to make it into the library. We'd love to make it better. From what I saw witnessing similar processes (C++, Boost, Python, Scala) - they all have some sense of awkward self-importance to them upon the first look. I think that's the way such things work. If D had a sound development process, I don't think we would be having the problems that we have today. I've discussed development process with a number of people who participated at such. They mentioned that until you get teams paid to work on the respective system (OS, language, framework etc) it all works on the basis of people doing things to scratch an itch they have. The critical mass is attained when there are enough people to cover a large enough itching area :o). If telling people what to work on on their free time works, I haven't succeeded at it and don't know anyone who has. Andrei
Dlangui can't build x64 example1.exe , because the size_t is ulong on winx64
Hi,everyone, I build the dlangui on win7 x64,use the debug win32,it can get the example1.exe, but use the debug x64,not get the exe file,the error is Error: function pointer FreeImage_OpenMemory (ubyte* data = null, uint size_in_bytes = 0u) is not callable using argument types (ubyte*, ulong) x:\GitHub\dlangui\src\dlangui\graphics\images.d 93 the reason is the function 'FreeImage_OpenMemory', it decalres that 'alias da_FreeImage_OpenMemory = FIMEMORY* function( BYTE* data = null, DWORD size_in_bytes = 0 )' ,but it's args is ulong. if the size_t not change on x64,and add the new 'longlength' maybe a good idea. Many Projects want to move on x64,but must modify the error 'size_t is ulong'. Then stop to do. if the size_t is not change, maybe a good idea. Frank.
Re: Dlangui can't build x64 example1.exe , because the size_t is ulong on winx64
On Saturday, 3 May 2014 at 08:59:40 UTC, FrankLike wrote: Hi,everyone, I build the dlangui on win7 x64,use the debug win32,it can get the example1.exe, but use the debug x64,not get the exe file,the error is Error: function pointer FreeImage_OpenMemory (ubyte* data = null, uint size_in_bytes = 0u) is not callable using argument types (ubyte*, ulong) x:\GitHub\dlangui\src\dlangui\graphics\images.d 93 the reason is the function 'FreeImage_OpenMemory', it decalres that 'alias da_FreeImage_OpenMemory = FIMEMORY* function( BYTE* data = null, DWORD size_in_bytes = 0 )' ,but it's args is ulong. if the size_t not change on x64,and add the new 'longlength' maybe a good idea. Many Projects want to move on x64,but must modify the error 'size_t is ulong'. Then stop to do. if the size_t is not change, maybe a good idea. Frank. Yes size_t is ulong on 64bits and uint of 32bit. Why would you need a new type? If you want it ulong or uint make it so. It should be implicit the conversion between uint and ulong. In the example you gave, I believe you should file a bug report with the developers.
Re: Math-Parser
On Friday, 2 May 2014 at 22:34:48 UTC, Tim Holzschuh via Digitalmars-d-learn wrote: Hi there, I currently try to write a simple math-parser in D. However.. something isn't working and I just can't figure out what's the problem. (I'm relative new to D, and this is my first test to write a parser/lexer) I'm pretty sure it's a simple layer-8-problem, but I always overlook it. While the Lexer seems to work, the Parser just sets _index - 0 (and I don't understand why..). If you would take a look at [1], I'd be very thankful.. Most probably this isn't a wrong use of something D-specific, it's more like I am stuck..^^ Thank you, Tim [1]: https://github.com/tholzschuh/math-parser General suggestions: Don't commit the build ext. files along with source code and in this case they aren't needed. Mono-D can load dub.json straight. As well as the obj/bin directories. With regards to your issues I have a suspicion about it being how your parse the tokens. Within the parser. Without really trying out atleast thats what I'm guessing.
Re: Math-Parser
On 05/03/2014 12:34 AM, Tim Holzschuh via Digitalmars-d-learn wrote:
Most probably this isn't a wrong use of something D-specific
Some of the problems are:
@property Lexer lexer() pure { return _lexer; }
If you change the result of a call to 'lexer' this will not change
'_lexer'. Mark the property 'ref' or get rid of it
if( !previous !token.type == TokenType.end )
popFront();
=
if(!previous token.type != TokenType.end) popFront();
Let me know if you also want hints on how to get the logic right.
Re: Postblit not invokable with MyStruct(MyStruct()); ?
On 05/03/14 01:05, Mark Isaacson via Digitalmars-d-learn wrote:
2) I ran into this issue while attempting to leverage the postblit for
code-reuse. In particular, I have a setup that is similar to:
struct A {
this(B b) { /* Stuff */ }
}
struct B {
}
void foo(T)(T param) {
auto a = A(param);
/* Stuff */
}
unittest {
foo(A()); //Fails
foo(B()); //Succeeds
}
The notion being that A and B are 2 ways to represent the same thing, why not
convert everything to the A format and proceed from there; I figured the
compiler would optimize out the pointless copy when T == A. Alas, as shown in
my unittest, foo fails to accept arguments of type A.
What actually fails is the initialization of 'a'.
Add another
this(A a) { /* Stuff */ }
constructor to the 'A' struct, and it will work.
And, yes, the missing cpctors are a language problem.
artur
ncurses linking(?) problem on Mac OS X
Hi,
I am very new to D, I just started with it a week ago or so, and
I haven't really been using compiled languages before (except for
Java), so I'm pretty confused with the whole thing in general. ;)
I try to use the ncurses library in my project using:
dependencies : {
ncurses : ~master
},
lflags : [-v]
But when I try to compile it, I get the following:
@(#)PROGRAM:ld PROJECT:ld64-236.4
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64
armv6m armv7m armv7em
Library search paths:
/usr/share/dmd/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld: library not found for -lncursesw
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
--- errorlevel 1
FAIL
.dub/build/application-debug-posix.osx-x86_64-dmd-4349FBA7803F9504BC9BF29263B86A68
text edit executable
Error executing command build: Link command failed with exit code
1
Terminated, exit code: 2
I have no idea where to go from here to be honest. It's probably
something easily fixed for someone even a tiny bit more
experienced.
I would love some help if anyone feels up to it.
Re: Error 42: Symbol Undefined for asserts
The problem I am running in to now is that Xamarin Studio now launches Test.pdb.exe which doesn't seem to do anything at all. Use visual d,it's simple for using pdb.exe
Re: ncurses linking(?) problem on Mac OS X
On 5/3/2014 9:36 PM, Joakim wrote: Terminated, exit code: 2 I have no idea where to go from here to be honest. It's probably something easily fixed for someone even a tiny bit more experienced. I would love some help if anyone feels up to it. Have you actually installed ncurses on your system? https://gist.github.com/cnruby/960344
Re: Error 42: Symbol Undefined for asserts
On Saturday, 3 May 2014 at 13:18:13 UTC, FrankLike wrote: The problem I am running in to now is that Xamarin Studio now launches Test.pdb.exe which doesn't seem to do anything at all. Use visual d,it's simple for using pdb.exe Which isn't really an option, Visual D is for Visual Studio and the express versions of VS don't allow 3rd party extensions. Also I am convinced it has something to do with Mono-D because debugging does work most of the time.
Re: ncurses linking(?) problem on Mac OS X
Have you actually installed ncurses on your system? https://gist.github.com/cnruby/960344 I will try this, but I did a search/info with homebrew and it said it was not recommended because OS X already has ncurses installed by default. Something about conflicts that could possibly occur. I found libncurses.dylib and such already installed in /usr/lib.
Re: ncurses linking(?) problem on Mac OS X
It worked perfecly. I knew I had missed something stupid. :) What confused me was the homebrew warning. Thank you for helping a newbie out. :)
Re: *** GMX Spamverdacht *** Re: Math-Parser
Am 03.05.2014 11:17, schrieb Rikki Cattermole via Digitalmars-d-learn: General suggestions: Don't commit the build ext. files along with source code and in this case they aren't needed. Mono-D can load dub.json straight. As well as the obj/bin directories. Yeah you're right, thank you. (And thank your for the Mono-D, dub thing, didn't know that..) Tim
Re: Math-Parser
Am 03.05.2014 13:29, schrieb Timon Gehr via Digitalmars-d-learn:
@property Lexer lexer() pure { return _lexer; }
If you change the result of a call to 'lexer' this will not change
'_lexer'. Mark the property 'ref' or get rid of it
How did I forget about Lexer being a struct is a value type...?
Thank you!
if( !previous !token.type == TokenType.end )
popFront();
My favourite. *g*
Let me know if you also want hints on how to get the logic right.
Would be very nice!
While 2*2 works, 2+2 throws an Error because the number-method gets an
END-Token instead of a Number-Token (although I'm not sure why).
Thank you,
Tim
Re: Math-Parser
On 05/03/2014 08:20 PM, Tim Holzschuh via Digitalmars-d-learn wrote: Let me know if you also want hints on how to get the logic right. Would be very nice! While 2*2 works, 2+2 throws an Error because the number-method gets an END-Token instead of a Number-Token (although I'm not sure why). Thank you, Tim Get rid of 'revert' and implement the parser in terms of range primitives. (The first thing you do in the while loops should be a popFront().)
Re: Postblit not invokable with MyStruct(MyStruct()); ?
What actually fails is the initialization of 'a'.
Add another
this(A a) { /* Stuff */ }
constructor to the 'A' struct, and it will work.
And, yes, the missing cpctors are a language problem.
artur
Thanks. Yeah, I figured I could do that, I was just hoping that I
could leverage the postblit.
Ultimately my answer to my second question became: Calling the
postblit directly is far too low level, just use std.conv.to
instead. to!A(x) did exactly the right thing (without any
modification of the original classes I think).
Error
I tried the following: dub install derelict but i only received the following error The 'install' Command was renamed to 'fetch'. Please update your scripts. Getting a release version failed: No package derelict was found matching the dependency =0.0.0 Retry with ~master... Fetching derelict ~master... Error executing command install: Couldn't resolve host name on handle D20220 Trying the fetch command leads to the same error. I hope somebody can help me. Thanks, Martin
map!(char)(string) problem
import std.algorithm;
int toInt(char c) { return 1; }
void main()
{
map!(a = toInt(a))(hello);
}
Can someone please explain why I get this:
Bug.d(10): Error: function Bug.toInt (char c) is not callable using
argument types (dchar)
^^^
D:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(425): Error:
template instance Bug.main.__lambda1!dchar error instantiating
D:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(411):
instantiated from here: MapResult!(__lambda1, string)
Bug.d(10):instantiated from here: map!string
D:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(411): Error:
template instance Bug.main.MapResult!(__lambda1, string) error instantiating
Bug.d(10):instantiated from here: map!string
Bug.d(10): Error: template instance Bug.main.map!((a) =
toInt(a)).map!string error instantiating
I thought that string == immutable char[], but this implies that it is
getting inferred as dchar[], I guess.
Dave
Re: map!(char)(string) problem
On Sat, 03 May 2014 14:47:56 -0700
David Held via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
import std.algorithm;
int toInt(char c) { return 1; }
void main()
{
map!(a = toInt(a))(hello);
}
Can someone please explain why I get this:
Bug.d(10): Error: function Bug.toInt (char c) is not callable using
argument types (dchar)
^^^
D:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(425): Error:
template instance Bug.main.__lambda1!dchar error instantiating
D:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(411):
instantiated from here: MapResult!(__lambda1, string)
Bug.d(10):instantiated from here: map!string
D:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(411): Error:
template instance Bug.main.MapResult!(__lambda1, string) error
instantiating Bug.d(10):instantiated from here: map!string
Bug.d(10): Error: template instance Bug.main.map!((a) =
toInt(a)).map!string error instantiating
I thought that string == immutable char[], but this implies that it
is getting inferred as dchar[], I guess.
All strings are treated as ranges of dchar by Phobos.
http://stackoverflow.com/questions/12288465
If you really want to operate on strings as ranges of code units rather
than code points, then you need to use std.string.representation and
convert them to the equivalent integral types (e.g. immutable(ubyte)[]).
- Jonathan M Davis
Conversion and Assignment on EnumUnion and EnumChain
I've put up a module https://github.com/nordlow/justd/blob/master/enums.d that provides two type constructors - EnumChain - EnumUnion that can be used to combine names or names-and-values from one or more enums. I would now like to define rules for assignments and implicit conversions with the following checks - Assignment to EnumUnion, EnumChain from its parts is always nothrow. - Assignment from EnumUnion, EnumChain to its parts may throw. to emulate Ada's subtype. Is it currently possible to implement any of these? Also do you think the namings EnumChain and EnumUnion are correct?
[Issue 12695] New: GIT HEAD : undefined symbols when -debug specified
https://issues.dlang.org/show_bug.cgi?id=12695
Issue ID: 12695
Summary: GIT HEAD : undefined symbols when -debug specified
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
import std.regex;
void main() {
``.replaceAll(regex(), ``);
}
Compiling with -debug gives :
Error 42: Symbol Undefined
_D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList11addIntervalMFNaNeiikZk
Error 42: Symbol Undefined
_D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList8dropUpToMFNaNekkZk
Error 42: Symbol Undefined
_D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList8skipUpToMFNaNekkZk
--
