Re: D2 port of Tango
I think that having tango for D2 could be useful, but I would be quite disappointed if Tango would still not get along with phobos. I understand that druntime might be quite connected to phobos releases, still there should be less reasons this time to fork also the runtime this time. That was always a pita IMHO, and I am a happy D1/tango user. Fawzi On Oct 19, 2011, at 11:12 PM, Andrej Mitrovic wrote: > On 10/19/11, Nick Sabalausky wrote: >> "zsxxsz" wrote in message >> news:j7mmkr$1fm0$1...@digitalmars.com... >>> I love Tango, because it's like using JAVA to program with Tango, and using >>> >>> C++ >>> to program with Phobos. Java is much more easy to program. >> >> Heh. The Java-ness of it is actually the one thing about Tango that I don't >> really like. 'Course, I'm a big Java-hater anyway, YMMV... >> > > Oh what, you don't like > getterAbstractFactoriesBuilderFactorySingletonObjectListener?
Re: Announcing: D support in SWIG
On 21-nov-10, at 18:27, klickverbot wrote: In a nutshell, SWIG is a »glue code« generator, allowing you to access C/C++ libraries from various target languages, including C#, Go, Java, Ruby, Python … and, since I merged my work into SWIG trunk a few days ago, also D, both version 1 and 2. I have put up a short description of it at my blog (http://klickverbot.at/blog/2010/11/announcing-d-support-in-swig/ ), but to give it a whirl, just head over to the SWIG SVN and build it from there (http://swig.org/svn.html). I would be glad if some brave souls could go ahead and test it in real-world use cases before it is officially released with SWIG for the first time (SWIG 2.0.2, date yet to be determined), so that any major bugs can be ironed out before. If you have any questions or suggestions, feel free to post them here, drop me a line, or ask right away in #D at freenode. While I am quite busy at the moment, I'd be happy to help you with any issues (particularly happy if they concern the SWIG side of implementing enhancements, obviously, but also simple usage questions). Besides that, as always, it would be nice just to hear about what you are using this for. Happy coding, David nice work David, I was following your github repository, nice that you made into the official repository. Fawzi
Re: DDT 0.4.0 released (formerly "Mmrnmhrm")
by the way DDT for me is http://www.allinea.com/?page=48 i.e. a distributed debugger On 20-nov-10, at 17:54, Jordi wrote: On 11/18/2010 03:52 AM, Bruno Medeiros wrote: I'm announcing the release of DDT (D Development Tools) version 0.4.0: http://code.google.com/a/eclipselabs.org/p/ddt/ (There was previously an older inactive project also called DDT, it has been renamed to EclipseD, with the authors permission.) The DDT project is a direct continuation of the Mmrnmhrm project. It has been renamed to reflect a more serious and unified approach to the Eclipse IDE project development. (although ocasional odd references might still be present in less conspicuous places ^_^ ) It has been 2 years since the last significant release, and this version has a lot of rough edges: Some newer D2 syntaxes are not yet supported (http://code.google.com/a/eclipselabs.org/p/ddt/issues/detail? id=6), and otherwise there are likely to be several parser bugs in the IDE (... you will be baked...). But it should provide for a minimally useful IDE, at least for simpler D projects. See http://code.google.com/a/eclipselabs.org/p/ddt/wiki/Features for a rough idea of what to expect. See also: http://code.google.com/a/eclipselabs.org/p/ddt/wiki/GeneralFAQ Changelog: == DDT 0.4.0 (2010-11-17) == * Renamed project to DDT * Updated IDE to latest DLTK version (2.0). * Fixed comment indentation character (was '#' instead of '//') on toggle comment actions * Fixed defaults bug in DeeRootPreferencePage and DeeEditorPreferencePage. * Added DEEBUILDER.COMPILEREXEPATH variable to builder, changed builder response file defaults. [No longer uses rebuild as the default] * Fixed parser to be able to parse expressions as the argument of typeid. * Added a parser workaround to allow parsing D source with annotations. * Fixed several parser bugs. * Removed Content Assist Templates preference page. I successfully installed it and i am testing it. I was using Descent at a very basic level and so far DDT looks good. Thanks for all the work!
Re: blip 0.5
On 18-nov-10, at 01:49, klickverbot wrote: On 11/18/10 1:12 AM, Bill Baxter wrote: Nice work! Is it for D2 or D1? Or both? --bb I hope you don't mind me answering, Fawzi: sure I don't mind, actually I hope more people will get involved :) Currently, it's D1 only. yes, indeed, I have considered D2, and there are things that I like about it, but as of now it is still too early for me to switch to it. - I am not too keen on fighting again will obscure threading bugs (but Sean is very helpfully considering my changes and adding them to druntime, so that might go well). - I need a stable 64 bit compiler, that is coming, but is not there yet - I feel that in general if I delay a bit my job will just get easier - D2 will need porting and testing, now I would rather use my library In any case that is a good topic, so I posted about it in digitalmars-d Fawzi
Re: Utah Valley University teaches D (using TDPL)
On 18-nov-10, at 09:11, Don wrote: Jonathan M Davis wrote: On Tuesday, November 16, 2010 13:33:54 bearophile wrote: Jonathan M Davis: Most of the rest (if not all of it) could indeed be done in a library. I am not sure it could be done nicely too :-) That would depend on what you're trying to do. Printing test success or failure is as simple as adding the approprate scope statement to the beginning of each unittest block. A bit tedious perhaps, but not hard. Right now unit tests follow the unix convention of saying nothing on success, That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option. I'm afraid that I have to disagree there. Having all of the successes print out would, in many cases, just be useless output flooding the console. I have no problem with making it possible for unit tests to report success, but I wouldn't want that to be the default. It's quite clear when a test fails, and that's what is necessary in order to fix test failures. I can see why a beginner might want the positive feedback that a test has succeeded, but personally, I would just find it annoying. The only real advantage would be that it would indicate where in the unit tests the program was, and that's only particularly important if you have a _lot_ of them and they take a long time to run. I think: "%d unit tests passed in %d modules" would be enough. This was already discussed, I think that optimal solution would be to have a testing function a bit like tangos, the testing functions knows how the module is called. Tango one always prints the module, but that is easy to change. What I use is my own testing framework, in it i have defined as default main function that checks commandline arguments, so that one can for example pass --print-level=error and see only the errors... See http://dsource.org/projects/blip/wiki/BlipOverview for an example of using it. This means having a special file to compile, that generates an executable dedicated to testing, but this maps well to how I do tests. In fact I often keep the tests separated from the code, I even hide them behind templates to avoid excessive template instantiation in some cases because they are large and would slow down the compilation... The current default unittest function runs very early (before main), so it is not possible to use that and use commandline arguments (which is "correct" because in the current model unittests can be activated for *any* executable, and should not disturb its run). It should be possible to write a test function that just sets up things for a later real unittest run that starts from main and can parse the commandline arguments, thus solving all these discussions... Fawzi
blip 0.5
I am happy to announce blip 0.5 http://dsource.org/projects/blip why 0.5? because it works for me, but hopefully it will work for others too, and 1.0 will be a release with more contributors... Blip is a library that offers * N-dimensional arrays (blip.narray) that have a nice interface to lapack (that leverages the wrappers of baxissimo) * 2,3 and 4D vectors, matrixes and quaternions from the omg library of h3r3tic * multidimensional arrays, with nice to use wrappers to blas/lapack * a testing framework that can cope both with combinatorial and random testing this means that you can define an environment (be it struct or class, maybe even templatized) and then define generators that create one such environment (see blip.rtest.BasicGenerators) then you can define testing functions that will receive newly generated environments and do the tests * serialization (blip.serialization) that supports both json format, that can be used also for input files and an efficient binary representation * MPI parallelization built on the top of mpi, but abstracting it away (so that a pure tcp implementation is possible), for tightly coupled parallelization * a Distribued Objects framework that does rpc via proxies (blip.parallel.rpc) * a simple socket library that can be used to connect external programs, even if written in fortran or C (for a weak parallel coupling) * a coherent and efficient io abstraction But what might be most interesting is. * SMP parallelization (blip.parallel.smp) a numa aware very flexible framework a parallelization framework that can cope well with both thread like and data like parallelism, integrated with libev to offer efficient socket i/o and much more. An overview of blip is given in http://dsource.org/projects/blip/wiki/BlipOverview The parallelization is discussed in http://dsource.org/projects/blip/wiki/ParallelizationConcepts finally to install it see http://dsource.org/projects/blip/wiki/GettingStarted enjoy Fawzi
Re: First big PITA in reallife D project
On 19-ott-10, at 20:30, Walter Bright wrote: Fawzi Mohamed wrote: I am not sure what is wrong in your case, and I worked only with D1/ tango on mac and linux, but I can definitely say that I had quite some very ugly bugs with threads and fibers, and gc. I think I have fixed all of them (at least everything seems stable now). Sean&co are welcome to take my fixes from tango into druntime, I release them with whatever license is needed: should I switch to D2 I will not complain if I don't have to debug those horrible things again... ;) Thank you! I (and I'm sure Sean) appreciate this! happy about it :)
Re: First big PITA in reallife D project
On 19-ott-10, at 12:45, Stephan wrote: Hey guys I wanted to discuss my first major depressing experience with D in a reallife project. First off here is the according bug report : http://d.puremagic.com/issues/show_bug.cgi?id=4951 I have to mention that it was by far not the first bug i encountered in D but it has never been such a PITA. I spent hours and hours of searching, rewriting and crawling my code for the cause of this issue. Just to finally find out that it was not my code but some bug in druntime. What i do: I spawn multiple threads all periodically connecting to some webservers waiting for the request to finish. Every request is totally independent of the others. There is no data sharing in my code. Now i have a protocol that makes my process send one last important request when shutting down. For a clean shut down i wanted to make sure that all the other threads are shut down first. That way the final request of the process is the very last. So i wait for every thread to finish their request and stop them. BUT it wont work like that. AFTER i stopped all other threads some strange behavior of druntime makes every creation of an InternetAddress instance (internally trying to resolve host) impossible (throws an exception). Additionally even if the Internet Addresses were created upfront the TcpSockets wont connect but throw. I have no idea what the heck is going on inside of the druntime that could cause this but in my opinion it makes designing a big server environment pretty much impossible because it would mean that i cannot let any of my user generated threads exit unless i want to shutdown completely anyway. Perhaps one side note: I am testing and having these issues under Windows. I have never been so tempted to use another language while coding in D as i was this time and that makes me sad. I am not sure what is wrong in your case, and I worked only with D1/ tango on mac and linux, but I can definitely say that I had quite some very ugly bugs with threads and fibers, and gc. I think I have fixed all of them (at least everything seems stable now). Sean&co are welcome to take my fixes from tango into druntime, I release them with whatever license is needed: should I switch to D2 I will not complain if I don't have to debug those horrible things again... ;) A non druntime bug you should maybe check if you use IP6 is the storage space you alloc for the address structure is large enough: sockaddr is too small, one should use sockaddr_storage (druntime is not always the culprit...). good luck Fawzi
Re: Do not use 2.041
On 11-mar-10, at 22:09, Steven Schveighoffer wrote: On Thu, 11 Mar 2010 16:05:51 -0500, bearophile > wrote: Steven Schveighoffer: Also if we get exception stack trace support, then you can immediately see everything. It's probably better to focus on that. OK. Do you want me to remove those two bug reports then? I think they should at least be marked as enhancements. Without a stacktrace printout, there is a need for such things. But I think exception tracing is coming, I think Tango already has it. -Steve Yes tango has it, there are a couple of things that are a bit clumsy, due to backward compatibility to previous implementations, but I think that the basic approach is sound: - separate function to trace addresses from the ones to resolve them - separate functions to find symbolic information, and those that demangle it) from those that print it out - try to avoid allocation (often the program is in a delicate spot when a stacktrace is requested, one should try to avoid making the position worse, and allocation in any case should be avoided when possible). I am willing to give the code I wrote in whatever license is needed, but I have used parts of code by h3r3tic, wm4 (winterwar), and Thomas Kühne, so if you want to use that code you should check also with them. Fawzi
Re: dmd 1.057 and 2.041 release
On 2010-03-09 20:15:44 +0100, Fawzi Mohamed said: [...] some html spam sorry about that...
Re: dmd 1.057 and 2.041 release
On 9-mar-10, at 18:56, Steven Schveighoffer wrote:
On Tue, 09 Mar 2010 12:33:01 -0500, Andrei Alexandrescu > wrote:
In wake of printing multi-dimensional arrays, I agree that start
and end delimiters should be present by default. If delimiters are
present, it only makes sense to make the array look like a D array,
so the ", " becomes an acceptable proposition.
That's great!
I'm unsure about strings - should "to" go all gung-ho on quoting
and escaping quotes etc.? That's a bit odd. Consider:
auto str = to!string("hello world");
I'd expect the call to be an identity application that makes str
equal to "hello world". So far so good. Then say I convert with
"to" an array of strings to a string:
auto str2 = to!string(["hello world"]);
Now str2 is "\"hello world\"", i.e. has an extra pair of quotes.
I think you mean "[\"hello world\"]"
well the thing is again str vs repr (string, or representation), repr
should output something that is basically valid D code that reproduces
the same value, whereas str not, what should to! do?
So "to" applied to an array does not always use "to" applied to
each element of the array - it has a completely different behavior.
I wonder whether that's a desirable behavior.
I would say no. I guess you could make the argument that strings
are already arrays treated specially, but I don't think it adds much
to put the quotes there. Plus, it allows simpler code and
documentation, you can define the conversion of an array as a purely
recursive function, even if it may not be implemented that way.
Note that ranges should convert identically to arrays, making arrays
special would make things odd.
Another thing that's unclear to me is whether writeln and "to"
should be defined such that
write(to!string(stuff))
and
writeln(stuff)
produce the same text. Currently that's the general plan, but I
wonder whether we should change the approach.
then I find it much better to base everything on something like my
void writeOut(T,S...)(void delegate char[]sink, T object,S formatting)
that outputs to a sink, so that you can have output without memory
allocation.
(well my version is little more complex because I want to accept also
other stuff not just a sink http://github.com/fawzi/blip/blob/master/blip/io/BasicIO.d
)
If you want a single string you can easily write helpers like
T[] collectAppender(T)(void delegate(void delegate(T[]))
appender,char[] buf=null)
or similar ( http://github.com/fawzi/blip/blob/master/blip/container/GrowableArray.d
) that convert sink based stuff to a single string.
I think that that design is very efficient and clean, well I have to
admit that I *hate* toString and methods that convert stuff to string,
because they are unnecessarily inefficent.
I like that, it shows consistency. If you want to change the
format, you can via to's parameters. But the most useful defaults
should be the same in writeln.
Even though to is a way to get a crude serialization function, I
don't know if it will be sufficient or efficient for a serious
serialization library (i.e. I don't think it's worth making 'to'
that smart). But it is sufficient as a debug tool, it just needs
better defaults.
as I said serialization is a different beast (at least what I want
from serialization), and the "how" should be in the target serializer,
the serialization function should given enough information to the
serializer, so that it might serialize how it pleases to him (in
particular meaningful labels should be given for serialization to
json,xml,...).
Fawzi
Re: dmd 1.057 and 2.041 release
On 9-mar-10, at 13:00, Steven Schveighoffer wrote:
On Tue, 09 Mar 2010 03:09:51 -0500, Alexander Suhoverhov > wrote:
Steven Schveighoffer at "Mon, 08 Mar 2010 15:23:51 -0500" wrote:
SS> On Mon, 08 Mar 2010 15:12:24 -0500, bearophile > wrote:
>> Steven Schveighoffer:
>>> Tell me how you would parse the following text serialization
string for a
>>> string[]:
>>>
>>> hello world how are you
>>>
>>> What if it was a string[][]?
>>>
>>> Compare that to:
>>>
>>> [hello world, [how are, you]]
>>
>> You are missing something:
>>
>> ["hello world", ["how are", "you"]]
SS> For completely unambiguous, yes. But still, I find often that
quotes are more noise than
SS> they are worth when just doing simple printouts. What we want
is the most useful
SS> default.
Commas are even more noise than than quotes. erlang:
[{app, "app1"}, {user, "user1"}, {score, 123456}, {date, 500},
{misc, "foo"}]
But if you just drop commas:
[{app "app1"} {user "user1"} {score 123456} {date 500} {misc
"foo"}]
If you are used to writing code, you should be used to having
commas. The two major use cases for 'to!string' are debugging and
maybe serialization, both programmer tasks. Plus, in your examples,
you have quotes for strings. That negates the need for commas, but
I don't know if having 'to' convert strings to having quotes only
for arrays makes sense. Outputting an array should be a recursive
thing. At the very least, we need either a non-whitespace separator
or quotes to delineate strings. Brackets are a must to see the
separation for multi-dimensional arrays.
-Steve
I don't know, I have something similar
writeOut(sink,type,formatting...), which is more flexible and
efficient, not just to string.
That is supposed to write out something for the user (no
serialization), and well it does not put "", but it does put "," in
arrays, but I can understand other choices (matlab for example has no
commas).
For dictionaries ":" and "," is nice I think.
It really come down to the meaning of to!(x), if it should be without
loss then one should have enough information to recover the original
value.
That is possible also without commas, but C/D programmers are used to
them... lisp, or other functional languages programmers might feel
more at home with spaces... both are possible.
I find it slightly funny that D would choose spaces, but in the end
any convention works
Fawzi
Re: dmd 1.057 and 2.041 release
On 2010-03-09 09:09:51 +0100, Alexander Suhoverhov
said:
Steven Schveighoffer at "Mon, 08 Mar 2010 15:23:51 -0500" wrote:
SS> On Mon, 08 Mar 2010 15:12:24 -0500, bearophile
wrote:
>> Steven Schveighoffer:
>>> Tell me how you would parse the following text serialization string for a
>>> string[]:
>>>
>>> hello world how are you
>>>
>>> What if it was a string[][]?
>>>
>>> Compare that to:
>>>
>>> [hello world, [how are, you]]
>>
>> You are missing something:
>>
>> ["hello world", ["how are", "you"]]
SS> For completely unambiguous, yes. But still, I find often that
quotes are more noise than
SS> they are worth when just doing simple printouts. What we want is
the most useful
SS> default.
Commas are even more noise than than quotes. erlang:
[{app, "app1"}, {user, "user1"}, {score, 123456}, {date, 500},
{misc, "foo"}]
But if you just drop commas:
[{app "app1"} {user "user1"} {score 123456} {date 500} {misc "foo"}]
SS> -Steve
For a basic output one can discuss what is better, but in general, for
a serialization approach I feel that the basic approach of the
discussion is flawed.
A much better approach (that for example I did use in my serialization
routines) is following the C++ philosophy that these details are
handled by the target stream, not by the function sending the data.
For example I have implemented two serializers, one that serializes to
json (with [,]""), and one that serializes to a binary format.
You write just one function, and then you can (even at runtime) change
the details on the output, even from textual to binary, without
changing anything in the serialization functions.
You don't want to write a different serialization function for each
format, or go around hunting for all calls to add " to strings...
Now in my serialization routines I have a couple of design choices that
maybe not everybody would share, but that I like:
- it is possible to get a meta information describing what will be
serialized *before* serializing (this helps in dumping the meta
information once at the beginning, and then serialize arrays with
minimal overhead in binary mode, but makes serializing slightly more
complex.
- it if possible (and not too difficult) to write serialization
routines fully by hand, without any template, something very useful for
objects that need special serialization. This method can also be fully
customized.
< shameless bug promotion>
By the way as I have some horrible code due to
http://d.puremagic.com/issues/show_bug.cgi?id=3472 and similar bugs in
mixing interfaces and templates, I had written a much nicer version
only to find out that it did not work...
I am transitioning the whole i/o in blip to a more abstract model based
on simple delegates (sink/readers) that should make it easier to use it
with either phobos or tango or any other source, but at the moment the
input part still requires tango InputStreams (output part already
transitioned).
Fawzi
Re: Tango 0.99.9 Kai released
On 11-feb-10, at 15:14, Moritz Warning wrote: On Thu, 11 Feb 2010 12:07:29 +0100, Jacob Carlborg wrote: On 2/11/10 06:11, strtr wrote: Nick Sabalausky Wrote: At the moment, no. Currently, Tango is D1-only, but druntime (the thing that is supposed to allow Tango and Phobos to play nice together on a single installation) is D2-only. So once Tango is ported to D2, I'd imagine there will probably be a Tango+DMD2 bundle that will include phobos and all your tango *and* phobos calls should work fine. But on D1, a DMD installation is either a tango one or a phobos one (unless you use some ugly hacks). I thought Tangobos was packaged in and would handle all Phobos calls without much hassle. Does it still work? Is it up to date ? Afaik, it's far from being up-to-date. yes, I had made it worka long time ago with gdc and dmd, but since then tango changed a lot and ldc was never kept into account, so I think that tangobos is not really an option. Fawzi
Re: dmd 1.050 and 2.035 release
On 2009-10-16 15:31:15 +0200, rmcguire said: Walter Bright wrote: digited wrote: So you don't mind that Tango is still uncompilable with 1.050 because of hurrying, I didn't know that. The bugzilla number which was posted as the reason it wouldn't compile was fixed. Hi Walter, could you not just put rc1, rc2, etc... at the end of the file names when you upload to server. This way we could tell if the release has been tested by the community, and you wouldn't have to change your release process much? Unless of course if it is all automated. -Rory Well I am not sure that it is really worth making a full release branching, just a tag and telling people that should become a release, and giving binaries to test it would probably be enough normally at least for D 1.0 where there shouldn't be large changes. I suppose that opening the development more brought in more peoples that don't write as defensively as W (or modifications of larger parts) and so more testing is probably good. In this specific case we were also probably a little bit sloppy at reporting problems, so that the went unnoticed for a couple of releases. I suppose that W wanted to fix regressions ASAP, which in general is good I think, just this time it played out a little badly. Anyway if W is willing a more formal release procedure would be good, but not absolutely necessary
Re: dmd 1.049 and 2.034 release
On 2009-10-13 01:56:11 +0200, Moritz Warning said:
On Mon, 12 Oct 2009 19:29:06 -0400, Nick Sabalausky wrote:
"Moritz Warning" wrote in message
news:hb01mo$23g...@digitalmars.com...
On Mon, 12 Oct 2009 15:53:28 -0400, Nick Sabalausky wrote:
"Moritz Warning" wrote in message
news:havc43$9a...@digitalmars.com...
On Sun, 11 Oct 2009 21:43:36 -0700, Walter Bright wrote:
[..]
If you're using tango trunk,
then I don't know what the problem is either...
It's trunk.
Maybe this?:
http://www.dsource.org/projects/tango/forums/topic/809
No, this is the first error:
/home/mwarning/trunk/build/runtime/../../runtime/common/tango/core/
Thread.d(659): Error: e2ir: cannot cast from tango.core.Thread.Thread to
void*
/home/mwarning/trunk/build/runtime/../../runtime/common/tango/core/
Thread.d(659): Error: e2ir: cannot cast from tango.core.Thread.Thread to
void*
Though, these cases work:
class Foo{}
Foo foo = new Foo();
auto x = cast(void*) foo;
A{ void* x(){ return cast(void*)this; } }
yet that is a strange error, I was not really able to reduce it, on one
side it is clearly a compiler error
(it does not allow cast(void*)this which is valid), on the other all
smaller cases that I could think of seem to work...
submitted it as
http://d.puremagic.com/issues/show_bug.cgi?id=3392
Fawzi
Re: Numpy Random Number Generators
On 2009-05-02 12:36:16 +0200, Michel Fortin said: On 2009-05-01 15:10:50 -0400, dsimcha said: IDK, I mean, I cut and pasted the code into my D IDE and tweaked it to get it to compile and then did some statistical tests to make sure the distributions were still reproduced faithfully. I didn't even change any of the variable names or code structure or anything in most cases. It's a straight translation, not a real reimplementation. I don't see how something like this could possibly *not* be considered a derivative work, and I think the people who wrote the original lib definitely deserve to be given credit. It's just that some of the BSD legalese is a little bit of a PITA for code that's in a standard lib. You can always ask for permission at the source. You never know, they may agree to allow you to put your D port under a license that'd work for Phobos. As long as there isn't too many copyright holders, it might work. otherwise adding the missing distributions (gaussian, exponential & gamma are already there, and done efficiently) to tango.math.random.Random would also be welcomed. Fawzi
Re: QtD 0.1 is out!
On 2009-02-28 14:54:26 +0100, Christopher Wright said:
Lutger wrote:
grauzone wrote:
Lars Ivar Igesund wrote:
Eldar Insafutdinov wrote:
We faced a bug that module static constructors don't work with cyclic
imports. Currently it's fixed with a dirty hack which is not really
acceptable. Is there any chance for this to be fixed?
IMO it is the cyclic import that is the bug ;)
Maybe all cyclic dependency bugs are on purpose, to teach people not to
use this evil D feature? Yeah, that must it be. I can't explain why
else these bugs/issues aren't fixed, and why people only reply with
incredibly useful statements like "but you shouldn't use this feature
anyway!".
Broken features should be either fixed or removed. This half-assedness
about it isn't really going to help D.
Well it's about cyclic dependency of initialization via module
constructors only right? Cyclic imports in general aren't (supposed to
be) broken, nor are module constructors.
And in point of fact, you can modify the runtime so it will not throw
exceptions on cyclic dependencies:
Index: genobj.d
===
--- genobj.d(revision 4339)
+++ genobj.d(working copy)
@@ -1098,11 +1098,7 @@
if (m.ctor || m.dtor)
{
if (m.flags & MIctorstart)
-{ if (skip || m.flags & MIstandalone)
-continue;
-throw new Exception( "Cyclic dependency in module " ~
(from is null ? "*null*" : from.name) ~ " for import " ~ m.name);
-}
-
+ continue;
m.flags |= MIctorstart;
_moduleCtor2(m,m.importedModules, 0);
if (m.ctor)
This opens you up to certain bugs, but they should be relatively rare.
I've tried it, and it appears to work.
Tango has it (thanks to lindquist) your change removes it :)
Re: New tango conference movies
On 2009-02-25 20:55:09 +0100, Peter Modzelewski said: Sorry for not giving any signs of life for so long but new job made me all occupied and I had little time to do anything else. But here I am - back with bunch of goodies: http://petermodzelewski.blogspot.com/2009/02/tango-conference-2008-rolling-dice.html http://petermodzelewski.blogspot.com/2009/02/tango-conference-2008-ldc.html You can download the slides from: team0xf.com/conference/rollingDiceTesting.pdf team0xf.com/conference/LDC.pdf Enjoy! Thanks Keyer! For those interested the randomized testing framework is part of blip: http://dsource.org/projects/blip Fawzi
Re: QtD 0.1 is out!
On 2009-02-27 21:49:58 +0100, Fawzi Mohamed said: On 2009-02-27 21:10:29 +0100, Walter Bright said: Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit. I fully agree, *avoiding* circular dependencies between modules is in general a good practice: a circular dependency it means that you have tight coupling, in in that case it is normally better to have everything in the same module to have a better control on it. Sometime one has cases in which circular dependencies arise, two ways to get rid of them are for example: 1) define and interface, the circular dependency is in the interfaces that are described in the same module, the two (or more) modules include the interfaces, and are not directly dependent on each other (only through the interfaces) 2) use templates, the circular dependencies are on a template parameter. The circular dependencies arise only upon instantiation
Re: QtD 0.1 is out!
On 2009-02-27 21:10:29 +0100, Walter Bright said: Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit. I fully agree, circular dependencies between modules is in general a good practice: a circular dependency it means that you have tight coupling, in in that case it is normally better to have everything in the same module to have a better control on it. Sometime one has cases in which circular dependencies arise, two ways to get rid of them are for example: 1) define and interface, the circular dependency is in the interfaces that are described in the same module, the two (or more) modules include the interfaces, and are not directly dependent on each other (only through the interfaces) 2) use templates, the circular dependencies are on a template parameter. The circular dependencies arise only upon instantiation
Re: Just one more thing...
On 2009-02-27 09:38:02 +0100, Walter Bright said: Anders F Björklund wrote: Walter Bright wrote: Can you upgrade to 10.5 ? It's only a few months left to "Snow Leopard", then we can play the same game all over again. Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is worth the effort. the worst offender (semaphores) are broken also on 10.5, I had to implement them on the top of mach semaphores in tango.
Re: Just one more thing...
On 2009-02-27 09:43:12 +0100, Walter Bright said: Anders F Björklund wrote: DMD is now the third D compiler to make it to Mac OS X, after GDC and LDC before it (based on same front-end). D2 needed to get there, too. Yes, I am very happy about this, now I might start playing with D 2.0 (in the spare time). But the wxD samples built successfully* with all three... Great!
Re: DMD-MAC!!
On 2009-01-29 23:19:25 +0100, Walter Bright said: Sean Kelly wrote: There are pthread calls for TLS which are implemented for OSX. But however it works (I haven't looked into it), it likely isn't as efficient or easy to deal with as the __thread storage class on other OSes. It won't be as efficient. But that really doesn't matter at this point - accessing global variables in a tight loop is a bad idea anyway. TLS just has to work. It can be optimized later as OSX improves (which it must, as TLS is going to be a bigger and bigger deal as time goes on). I don't agree so much with this, TLS can be useful is some occasions but should be used very sparingly in my opinion, it should be used mostly for the infrastructure, not by the end user. TSL is an evolution of global variables and still has many of their drawbacks, if possible one should pass the variables explicitly, often with some care, and maybe grouping them into structure it turns out to be easier than one thinks, and the effort costs little typing. There are things where TSL can be very useful, and I use it for example to make the scheduling interface nicer, but I think that with good design those cases are few... Encouraging wide use of TSL is bad in my opinion (not that you are doing it, but one might interpret it like that). Fawzi
Re: Bug #2429 [ was DMD 1.037 and 2.020 releases]
On 2008-12-09 11:10:33 +0100, Fawzi Mohamed <[EMAIL PROTECTED]> said: On 2008-12-08 19:06:42 +0100, Kagamin <[EMAIL PROTECTED]> said: torhu Wrote: Tango also opens files for writing with shared reading disabled by default. I'm not sure why, but maybe someone can remember the reason for it. they just forgot? :) consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi Anyway you can try to file a ticket to change the default if you want...
Re: Bug #2429 [ was DMD 1.037 and 2.020 releases]
On 2008-12-08 19:06:42 +0100, Kagamin <[EMAIL PROTECTED]> said: torhu Wrote: Tango also opens files for writing with shared reading disabled by default. I'm not sure why, but maybe someone can remember the reason for it. they just forgot? :) consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi
Re: TempAlloc
On 2008-12-07 18:44:30 +0100, dsimcha <[EMAIL PROTECTED]> said: == Quote from Fawzi Mohamed ([EMAIL PROTECTED])'s article it could simply be an int storing the place in the stack... So if someone forgets to remove the frame the next call will see it immediately. By the way couldn't you avoid the thread local State by simply keeping a stack of State structures? Then instead of the thread local State you would simply look at the top of the State Stack, it should be faster and more self contained. I really don't see how this can work. AFAIK, there are only 4 ways to deal with global mutable state in a multithreaded program: 1. Locking. 2. Somehow do everything atomically, if you can. 3. Make the "global" state thread-local. 4. Eliminate it altogether. The biggest reason for me writing TempAlloc in the first place was to avoid lock contention for GC malloc access. TempAlloc is somewhat faster even in single-threaded tests, but the really huge, orders of magnitude speedups come when it's used to avoid this contention. mmh sorry this comes from not having really understood how TmpAlloc was supposed to work. Indeed if you want to hide completely the presence of a State, and not pass it explicitly to the allocation routines you cannot avoid thread local. I was mislead by the name, State is actually the superstack object, what I meant was to keep an extra index in it that simply counts the number of frames, and return/ask it in initFrame freeFrame so that you can check that you did not have any mismatched frames.
Re: TempAlloc
On 2008-12-06 15:55:44 +0100, dsimca <[EMAIL PROTECTED]> said: == Quote from Fawzi Mohamed ([EMAIL PROTECTED])'s article I think that it could be useful to add an argument to to frameInit/free, in any case not just to speed things up, but to quickly catch mismatched init/free calls. Can you elaborate on this? I'm not exactly sure what such an argument would look like. Also, I wanted to make TempAlloc fairly simple even if it costs some performance so that I would actually want to use it. If doing something like this adds a lot of complexity for the caller, I probably won't implement it. Right now, I like the simple mixin API. it could simply be an int storing the place in the stack... So if someone forgets to remove the frame the next call will see it immediately. By the way couldn't you avoid the thread local State by simply keeping a stack of State structures? Then instead of the thread local State you would simply look at the top of the State Stack, it should be faster and more self contained. Then the element to check could really be the size of the stack, and if it is simply an int you can make it optional, if present you check for mismatches... and you get rid of passing the State out... int initFrame()// returns the number of frames of the stack void freeFrame(int handler=-1)// frees the frame, if handler is >=0 then checks the number of frames using GC.malloc in malloc for large requested sizes kind of defeats the stated purpose (and what makes superstack more difficult to use) of not being GC scanned, even if I understand the problem of either making bookkeeping more complicated or create potentially big holes in the stack... I see over 4MB in a single allocation to be kind of a corner case anyhow. If you need to allocate this much memory for a temp variable that doesn't escape the current scope, in a single allocation (probably pretty unusual already), since the cost of an allocation is sublinear in bytes allocated, the allocation time will likely be dwarfed by the time it takes to use the memory for whatever you need it for. Furthermore, whether by frameInit/frameFree or by TempAlloc.malloc/TempAlloc.free, the memory gets freed deterministically rather than waiting for the GC to run to free it, so it's still faster than using new, etc. In fact, I'm thinking I should have made this limit ~1MB (about 1/4 the size of a TempAlloc block) since allocating 4MB will always require the creation of a new block anyhow. I'm open to suggestions about how to deal with these large block cases, but I will prioritize handling the common case of much smaller allocations efficiently and cleanly over what I feel is somewhat of a corner case. no problem I understand, and I am not a user yet. OT: I just read (when looking for your previous messages) about your statistics library. Nice! You might be interested in giving a look to tango's random package, it has fast generation of accurate random bumbers with gauss exp and gamma distributions... D1.0, but bringing it to D2.0 shouldn't be difficult... Fawzi
Re: TempAlloc
On 2008-12-06 00:20:49 +0100, dsimcha <[EMAIL PROTECTED]> said: As per a discusson on digitalmars.D about a month ago, I've created a temp space allocator for quickly allocating memory in a last in, first out manner. Its main use is for allocating scratch space to be used within a function without introducing threading bottlenecks, etc. I've released it as an alpha on scrapple. I'm working on a major update to my statistics library (also on scrapple) and will dogfood this there when I'm done with the update. I think that it's pretty useful, at least in number crunching-type code, in its current form as a library. However, it might be even better if integrated into druntime and the core language to make it safer (it's pretty dangerous if used incorrectly) or cleaner to use (I've done the best I can here, but if I had some compiler support, I could automate some stuff that I make the caller do.) For the code, see http://dsource.org/projects/scrapple/browser/trunk/tempAlloc. The code is for D2 only, but could probably be ported to D1 using Tango's thread-local storage. I think that it could be useful to add an argument to to frameInit/free, in any case not just to speed things up, but to quickly catch mismatched init/free calls. using GC.malloc in malloc for large requested sizes kind of defeats the stated purpose (and what makes superstack more difficult to use) of not being GC scanned, even if I understand the problem of either making bookkeeping more complicated or create potentially big holes in the stack... Fawzi
Re: Tango Conference 2008 - DReactor talk by Rick Richardson
On 2008-11-02 18:53:14 +0100, "Denis Koroskin" <[EMAIL PROTECTED]> said: On Sun, 02 Nov 2008 20:46:16 +0300, Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: Peter Modzelewski wrote: And yet another video from Tango Conf 2008. DReactor this time: http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-dreactor-talk.html slides can be found here: http://team0xf.com/conference/DReactor.pdf Enjoy! :D Other videos: DWT: http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-dwt-talk-video.html MiniD: http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-minid-talk-video.html Fibers: http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html Compiler workshop: http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-compiler-and.html I remember there was talk about a list of language-related issues that came up during the conference. Is that list available? Andrei http://www.prowiki.org/wiki4d/wiki.cgi?TangoWorkshopResults (Fawzi Mohamed posted this link some time ago, IIRC) I was too slow ;)
TangoWorkshopResults
On 2008-11-02 18:46:16 +0100, Andrei Alexandrescu <[EMAIL PROTECTED]> said: I remember there was talk about a list of language-related issues that came up during the conference. Is that list available? Andrei maybe you mean this http://www.wikiservice.at/wiki4d/wiki.cgi?TangoWorkshopResults Fawzi
