Do AAs allocate on removal?
Hello,
I'm just bitten by some occasional finalize exceptions in a wxd program
I'm writing on a OpenSuse 64 bit linux host with dmd 2.64.2.
I was able to track it down to a bug in wxd, where the wxObject
destructor tried to remove the object from a static map.
some code from wxObject:
~this()
{
Dispose();
}
public /+virtual+/ void Dispose()
{
if (wxobj != IntPtr.init)
{
//bool still_there = RemoveObject(wxobj);
//lock (typeof (wxObject)) {
if (memOwn /* still_there*/)
{
dtor();
}
//}
RemoveObject(wxobj);
wxobj = IntPtr.init;
//memOwn = false;
}
//GC.SuppressFinalize(this);
}
// Removes a registered object.
// returns true if the object is found in the
// Hashtable and is removed (for Dispose)
public static bool RemoveObject(IntPtr ptr)
{
bool retval = false;
if (ptr != IntPtr.init)
{
if(ptr in objects) {
//gw 20131207 objects.remove(ptr); -- here the
application goes boom, so i replaced it with the following line
objects[ptr] = null;
retval = true;
}
}
return retval;
}
// Hashtable to associate C++ objects with D references
private static wxObject[IntPtr] objects;
As you can see, the problem is that wxObject destructor tried to remove
an entry from a static AA. Replacing the removal with just nulling the
value solves the problem. But now I have to implement a cyclic cleanup
routine wich removes the nulls from the AA. I really don't want to do that.
I suspect that the AA reorganized (with allocation) when an element is
removed. I think it is a good idee if this can be delayed until the next
insert, so that remove can be used in finalizers.
I also don't have a clue why the object gets collected when it is
referenced in the static map.
Gerrit Wichert
Re: Do AAs allocate on removal?
Am 07.12.2013 19:07, schrieb thedeemon:
A quick glance into the source shows that removing an entry does not
allocate, but calls GC.free(). Inserting an entry does allocate.
Rehashing happens when entries are added, not when they are removed.
Check your destructors again, make sure they are not called twice.
Thanks for your quick answer. So the call to GC.free() breaks it. Seems
easy to fix, just don't free and let the GC do its work. Whatever, I've
solved my problems by nulling out the value and calling a cleanup
routine before the next entry is added.
private static void cleanObjects()
{
if (shouldCleanObjects) {
foreach (key, val; objects) {
if (!val) {
objects.remove( key);
}
}
shouldCleanObjects = false;
}
}
Seems to work, but I'm not shure if it is save to remove entrys while
iterating. Can't find any advise at this.
Gerrit Wichert
Re: The Right Approach to Exceptions
On 19.02.2012 01:40, H. S. Teoh wrote: One word: internationalization. Then toString() falls flat on its face. You can't even fix this by having Phobos do the translation internally. You can't expect users of Phobos to only ever support languages that Phobos has been previously translated to, for one thing. That would be a crippling disability. T Its even better, i want the exception message to be shown to the user in the current locales language. But for the logs i want it to be in english since i have to maintain systems in other countries we sold our software to. Its easy to connect to a remote system on the other side of the world, but its not so easy to read log files in a foreign language.
Re: wxC wxD (aka: let's work together with wxhaskell project)
Hello, i think wxC is a very special 'binding' that can work as a basic layer for multiple language 'bindings'. As such the optimal solution would be if there is only one wxC that is part of wxWidgets itself. The natural choice for the build system is then wxWidgets own build system. So it would be more easy to keep it in sync with WxWidgets. Developers of all language bindings can unite their forces on it. Maybe even wxWidgets core developers would like to care for keeping it in sync if it is not to much work. Sharing wxWidgets build system, wxC can be build on the same target platforms as wxWidgets. btw. does wxD currently build for you? I got some trouble with deprecated typedef and others on my linux box. But i've just finished fixing it and DMD 2.057actually successfully builds the little testing app i'm developing to become more acquainted with D. It is tested under Linux 32 bit only (OpenSuse 11.4 + Open Suse 12.1/64 using -m32) but i think it should also work on Windows. if you want to give it a try, checkout the 'dmd257linux' branch from https://github.com/gwichert/wxd I woud like to get some feedback on this before making a pull request. Gerrit
Re: [bindings/win32] Migration from typedef
On 22.12.2011 12:28, Andrej Mitrovic wrote: I'd like to know this too. Currently wxd won't link if I change a typedef to an alias due to multiple definitions. I've had the same problems here on my linux box + some others. But i've just finished fixing them and DMD 2.057actually successfully builds the little testing app i'm developing to become more acquainted with D. It is tested under Linux 32 bit only (OpenSuse 11.4 + Open Suse 12.1/64 using -m32) but i think it should also work on Windows. if you want to give it a try, checkout the 'dmd257linux' branch from https://github.com/gwichert/wxd Gerrit
Re: wxC wxD
So, is wxD going to continue like now, or do you envision some change how to proceed for wx-2.9/3.=? I don't plan to do anything with it, I put it up on github so that it could be forked and maintained if there are any bugfixes etc needed... So if i understand you right, the way to keep wxD alive ist to fork your repository and continue it as an independent project ?
Re: amd64 install dmd2.055
I have installed dmd 2.055 on my 64 bit openSuse box. It first asked for affirmation of the adobe reader Eula and then silently failed to install the new dmd version. I tried three times with all the same outcome. Then i removed the old dmd installation and the next install try succeeded. Am 25.09.2011 00:56, schrieb dsmith: Has anyone here succeeded with a dmd2.055 one-click install to Linux amd64? Unlike the prior dmd2.0xx, I have no luck with dmd2.055 for amd64 installs. I've tried Debian, Fedora, and Suse. After some command line work (based on http://www.d-programming-language.org/dmd- linux.html), it appeared to install on Debian6 only to give an error with a test program ... error: libstdc++.so.6: wrong ELF class
C-ABI bug returning string/struct on linux 32 bit when using wxd ?
Hello,
shortly i tried to use wxd for building a native 64 bit application on
my OpenSuse 11.4 - 64 bit box. Sadly i ran into issue 5570 wich stopped
me from building a woking wxd lib. So i stepped back to build the app
for 32 bit. This worked up to the point where i tried to use a
HtmlListBox control. Here i encountered a segmentation fault when this
cpp method tries to execute a D callback function.
htmllbox.cpp class _HtmlListbox:
wxString OnGetItemMarkup( size_t n) const
{ wxc_string tmp = m_OnGetItemMarkup(m_dobj, n); return wxstr(tmp); }
HtmllistBox.d:
static extern(C) private string staticOnGetItemMarkup(HtmlListBox
obj,size_t n)
{
return obj.OnGetItemMarkup(n);
}
The debbuger shows me that the calling cpp function pushes the tmp
pointer on the stack as the first parameter while the D function seems
to expect the obj as first parameter.
This happens with the 64-bit suse-rpm DMDs in versioons 2.54 and 2.55.
I can't find anything about this in the bugtracker, so i would like to
know if this is really a bug or if wxd is on the wrong path.
Btw. i can't find a link to the bugtracker on the dpl.org page.
Gerrit Wichert
Problem passing string to cpp on 64bit linux
Hello,
currently i'm trying to get wxD running on my opensuse 11.4 64bit box.
I've got it running before on opensuse 11.3 32bit using dmd 2.41 (with
some little tweaking to the wxd sources).
After Upgrading my box, I installed the 64bit version of dmd 2.43 and
tried to compile it in 64bit mode. It needed a little more tweaking
(casting down some length properties where wxWidgets expected int), but
finally I got it to compile and link with my app. But when I tried to
run it I only got a segfault.
Using GDB on it I was able to locate the problem. For passing strings to
cpp wxD makes use of a neat little trick.
Strings were just passed to a C function expecting a struct of type
'dstr' like in this testing code.
app.d
import std.stdio;
// struct d_str {
//size_t length;
//const(char) *data;
//this( string text) {
// length = text.length;
// data = text.ptr;
//}
// }
// static extern (C) void cpp_test( d_str text);
static extern (C) void cpp_test( string text);
void main( string[] args) {
//d_str dtext = this is a testcall;
string dtext = this is a testcall;
cpp_test( dtext);
}
test.cpp ==
#include stdio.h
#include string.h
struct dstr {
size_t length;
const char* data;
};
extern C
void cpp_test( dstr ctext) {
printf( string is: %.*s\n, (int)ctext.length, ctext.data);
return;
}
===
compiled with:
g++ -g -Wall -c -o test.o test.cpp dmd -gc test.o app.
As said above this worked fine in 32 bit mode but stopped working when
compiled in 64 bit mode.
The received struct in the called cpp function just contains garbage.
The calling and receiving functions disassemble to the following sequences.
Dump of assembler code for function D main:
0x0045ae40 +0: push %rbp
0x0045ae41 +1: mov%rsp,%rbp
0x0045ae44 +4: sub$0x10,%rsp
0x0045ae48 +8: mov0x3fdb9(%rip),%rdx#
0x49ac08 _TMP0+8
0x0045ae4f +15:mov0x3fdaa(%rip),%rax#
0x49ac00 _TMP0
0x0045ae56 +22:mov%rax,-0x10(%rbp)
0x0045ae5a +26:mov%rdx,-0x8(%rbp)
0x0045ae5e +30:rex.W push %rdx
0x0045ae60 +32:rex.W push %rax
0x0045ae62 +34:callq 0x45adf4 cpp_test(dstr)
0x0045ae67 +39:add$0x10,%rsp
0x0045ae6b +43:xor%eax,%eax
0x0045ae6d +45:leaveq
0x0045ae6e +46:retq
End of assembler dump.
Dump of assembler code for function cpp_test(dstr):
0x0045adf4 +0: push %rbp
0x0045adf5 +1: mov%rsp,%rbp
0x0045adf8 +4: sub$0x10,%rsp
0x0045adfc +8: mov%rdi,%rdx
0x0045adff +11:mov%rsi,%rax
0x0045ae02 +14:mov%rdx,-0x10(%rbp)
0x0045ae06 +18:mov%rax,-0x8(%rbp)
0x0045ae0a +22:mov-0x8(%rbp),%rdx
0x0045ae0e +26:mov-0x10(%rbp),%rax
0x0045ae12 +30:mov%eax,%esi
0x0045ae14 +32:mov$0x49abc4,%edi
0x0045ae19 +37:mov$0x0,%eax
0x0045ae1e +42:callq 0x45a728 printf@plt
0x0045ae23 +47:leaveq
0x0045ae24 +48:retq
End of assembler dump.
If I interpret this right then the problem is D pushing the array on the
stack while cpp is expecting the structs values in the rdi and rsi
registers. The GDB command 'ptype dtext' returns 'type = ucent' for the
D string type. Since this is a 128 bit type I thought it may be passed
on the stack because it doesn't fit in the registers.
I the tried to pass an explicit struct (outcommented code) but with the
same outcome. It also seems to be passed on the stack.
So now I'm at the end of my wits. Is this expected or a bug in the 64bit
linux implementation? And what can i do to keep this neat little trick
alive?
Gerrit Wichert
Re: DIP11: Automatic downloading of libraries
Am 14.06.2011 22:22, schrieb Andrei Alexandrescu: It's not hard, in fact that's almost how we want to implement it: a straight function that wraps a call to wget. The difference is that you'd migrate the function into a separate utility, and I think that's a good idea. (Walter prefers it inside the compiler.) It even seems to be possible that this 'plug-in' tool can become a source code provider which not only downloads the files for dmd to read them, but pipe their content directly back into the compiler. I really can't imagine what possibillities this may offer.
Re: Against enforce()
I would say it is a bug in the contract.
The signature is not normalized and the user gets a chance to provide
conflicting parameters. I think that it would be best to deduce the
direction
from the order of the start and end parameters. Then the stepsize can be
made
absolute.
Am 18.03.2011 09:14, schrieb Kagamin:
So this is a bug? This is a contract, not a validation of user input.
struct Iota(N, S) if ((isIntegral!N || isPointer!N) isIntegral!S)
{
private N current, pastLast;
private S step;
this(N current, N pastLast, S step)
{
enforce((current= pastLast step 0) ||
(current= pastLast step 0));
this.current = current;
this.step = step;
Re: Reading a line from stdin
Am 16.03.2011 11:09, schrieb spir: This is a design bug. 99% of the time one does not want the newline, which is not part of the string data, instead just a terminator. Even more on stdin where it is used by the user to say Im done!. If the text is written back to the output /and/ newline is needed, it's easy to add it or use writeln. This is a very interesting statement and absolute contrary to my experience. I think It is never a design bug for a standart function to forward as much information as possible. Suppressing unwanted information is very easy, but getting back some information that has been cut off by a courteous tool is an awful job. That data comes in via stdin doesn't mean is is typed in by the user. It's perfectly possible that it is piped in and that the line endings should not be touched. You must be a very lucky person if you have never been bitten by such a courteous piece of over engineered software. I hope you can continue being lucky for a long time. :-) Gerrit
Re: Should we have an Unimplemented Attribute?
Am 02.02.2011 23:59, schrieb Andrej Mitrovic: But what about structs/classes/functions/etc which are partially implemented, but still unusable? Marking them with deprecated doesn't make sense, as this will likely confuse both the user and the library writers. Would it be overkill to introduce a new attribute? What about version( comming_soon) ? :-)
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
Am 14.01.2011 15:34, schrieb Steven Schveighoffer: Is it common to have multiple modifiers on a single character? The problem I see with using decomposed canonical form for strings is that we would have to return a dchar[] for each 'element', which severely complicates code that, for instance, only expects to handle English. I was hoping to lazily transform a string into its composed canonical form, allowing the (hopefully rare) exception when a composed character does not exist. My thinking was that this at least gives a useful string representation for 90% of usages, leaving the remaining 10% of usages to find a more complex representation (like your Text type). If we only get like 20% or 30% there by making dchar the element type, then we haven't made it useful enough. I'm afraid that this is not a proper way to handle this problem. It may be better for a language not to 'translate' by default. If the user wants to convert the codepoints this can be requested on demand. But pemature default conversion is a subltle way to lose information that may be important. Imagine we want to write a tool for dealing with the in/output of some other ignorant legacy software. Even if it is only text files, that software may choke on some converted input. So i belive that it is very importent that we are able to reproduce strings in exact that form in which we have read them in. Gerrit
Re: Verbose checking of range category
Hello,
maybe the template resolver can provide some kind of buffer where
the constrains can emit their messages to.
If finally a match is found the buffer can be discarded. If not the
messages can be printed.
So we only get messages for failed template instantiations.
Am 11.12.2010 18:15, schrieb Andrei Alexandrescu:
Hello,
Following Craig's questions about sort(), I was thinking of the
following idea. How about defining a flag rangeCheckVerbose that emits
explanatory messages during compilation whenever a range check fails?
Consider this prototype:
import std.stdio;
version = rangeCheckVerbose;
template isRandomAccessRange(T) {
enum isRandomAccessRange = isRandomAccessRangeImpl!T.value;
}
template isRandomAccessRangeImpl(T) {
enum hasEmpty = is(typeof(T.init.empty));
enum hasFront = is(typeof(T.init.front));
enum hasPopFront = is(typeof(T.init.popFront()));
enum hasIndexing = is(typeof(T.init[1]));
enum hasSlicing = is(typeof(T.init[1]));
enum value = hasEmpty hasFront hasPopFront hasIndexing
hasSlicing;
version (rangeCheckVerbose) {
static if (!value) {
pragma(msg, Type ~ T.stringof ~ is not a random
access range because:);
static if (!hasEmpty)
pragma(msg, no empty property);
static if (!hasFront)
pragma(msg, no front property);
static if (!hasPopFront)
pragma(msg, no popFront method);
static if (!hasIndexing)
pragma(msg, no indexing);
static if (!hasSlicing)
pragma(msg, no slicing);
}
}
}
void main()
{
writeln(isRandomAccessRange!int);
}
This program will generate a valid executable, but will also print
during compilation:
Type int is not a random access range because:
no empty property
no front property
no popFront method
no indexing
no slicing
When a programmer has an odd issue with a range check, turning
verboseness of checks could help.
What do you think?
Andrei
Re: Ddoc to PDF
Am 17.10.2010 19:45, schrieb Walter Bright Apparently, it is fairly simple to convert plain text files to PDF. http://re-factor.blogspot.com/2010/10/text-to-pdf.html Which suggests to me it should be equally simple to create a Ddoc macro file to allow Ddoc to emit pdf files directly. Anyone want a nice weekend project to product this? I don't think that it is the best idea to produce a pdf in one step. First PDF is really complicated (and also evolves over time). Second this would require dmd to determine the layout of the generated documentation. We could easily avoid the frist point. When we just make ddoc generating xsl-fo a tool like apache fop can be used to generate pdf or html from it. This is what xsl-fo is designed for. It's not rocket science to create a xsl-fo layout. But the second problem remains. If i where a company or community writing libraries in d i would like to have some corporate identity in it. This means that I want to decide over the layout. So i would really prefer if ddoc were *additionaly* able to generate a pure semantical version of the document data that is easy to mess with an external tool. This can be a simple xml file which i can feed into my own transformation pipline. This way ddoc does the part it can really shine on, extracting the information, and delegates the rest to something that knows more about the wishes of the actual user. This shuoldn't mean that ddoc should stop generating unified standart documentation. But i think it is worth a thought to generate semantic data files on request. Gerrit
automatic code examples in documentation
This is a post i made deep in the 'improving the join function' thread.
Steven asked me to open a new thread on it, so here it comes.
Am 13.10.2010 22:07, schrieb Andrei Alexandrescu:
Good point. On the other hand, an overly simplified documentation
might hinder a good deal of legit uses for advanced users. I wonder
how to please everyone.
I think the best way to explain the usage of a feature are *working*
code-examples.
Maybe it's possible to have a special unit-test block named such as 'example'.
The compiler can completely ignore such sections or just syntax check them, or
... .
For doc generation they are just taken as they are and put into (or linked to)
the documentation.
It may be even possible for the doc generator to compile and run these samples,
so they become some kind of unit test and their possible output
can be part of the documentation.
Just an idea that comes to my mind
This was the original post, now some more explanation:
How can the syntax look like ?
... library code
@documentation( code) {
//hello world example code
import std.stdio;
void main() {
writeln( Hello, world!);
}
}
more library code ...
This is how a simple example code section may look like.
The @documentation annotation tells the compiler not to generate any code
from the section. The minimal thing it has to do is generate a string from
the section content and forward it to the document-generator.
This should be sufficient for easily getting code examples into the
documentation.
I think its a good idea if the compiler executes a syntax check on the example
section,
like it does on the already implemented syntax checked strings.
Then the compiler part is done with this. This are code examples, not unit
tests.
They are not run with the other unit tests.
I think code examples are most usefull if they are self-contained little
programs.
Part of the document generation may be to compile and run the extracted
examples.
When a example does't compile it can be marked as defunct or excluded from the
documentation. The doc-generator can catch the output of the running examples
and add it to the documentation as result.
Shurely there are some problems when trying to compile the examples like wich
libs to link with, or what about GUI-code, or just code snippets, but for me
this is all secondary, maybe we can make that work later. The most important
part
is to define the transfer mechanics to get the example code into the
documentation.
So what do you think?
Gerrit
Re: improving the join function
Am 13.10.2010 22:07, schrieb Andrei Alexandrescu: Good point. On the other hand, an overly simplified documentation might hinder a good deal of legit uses for advanced users. I wonder how to please everyone. I think the best way to explain the usage of a feature are *working* code-examples. Maybe it's possible to have a special unit-test block named such as 'example'. The compiler can completely ignore such sections or just syntax check them, or ... . For doc generation they are just taken as they are and put into (or linked to) the documentation. It may be even possible for the doc generator to compile and run these samples, so they become some kind of unit test and their possible output can be part of the documentation. Just an idea that comes to my mind Gerrit
Re: Function calls
Hello,
I think the biggest part of our problem with @property is, that we are
using the wrong words. I'm no native english speaker so it may be that
i'm totaly wrong with this, but that's my impression. When i hear the
word property i'm thinking: ok, this is a well defined part of the
internal state of that object instance that i'm allowed to interact
with.
That's what i think a property is. It is not about parentheses or not
parentheses. It is not about just marking functions to change their call
behaviour.
I think a property should be about *first* naming and defining a
distinct part of the object state and thereafter *optionally* defining
how to deal with it.
I really don't want to talk much about syntax but i like the way
Moose has solved this problem for Perl5. Even if its syntax is not
compatible to a C derived language language like D (btw. why not?), a
quick skim of its documentation may be a source of inspiration. It
clearly was for me.
http://search.cpan.org/~drolsky/Moose-0.94/lib/Moose.pm
The coolest thing about Moose is, that it doesn't change the language
of Perl5 in any way. For attributes (their name for properties) it just
implements a declarative syntax that is valid perl code and executed at
compile time to define fields and accessor functions.
so a simple
has 'x' = (is = 'rw', isa = 'Int');
just defines a field that can hold an integer and two accessor functions
x() and x(int). The name of the real field and how it is stored is
adjustable but defaults to the way perl objects are normaly constructed.
has 'x' = (is = 'ro', isa = 'Int');
just omits constructing a write accessor.
To be exact at this a readonly property doesn't mean it is const, it
means that you don't have a write accessor and therefore can't
substitute its content. You can get a mutable subobject or struct via a
read accesseor and manipulate it via its own property accessors but you
can't substitute it since you have no write accessor. If you don't want
to let the client manipulate intenal state via a read accessor of a
complex property just make it return a const subobject.
Semantically this turns a property into a little sub-class even if it is
not defined as such. It is implemented as old school fields and accessor
functions. But they are auto generated until you feel the need to define
them explicitly. There are much more ideas in Moose that may be
applicable to D that i won't go any deeper in here. Please skim it's
documentation if you're interested. For me it has turned Perl into
something beautiful while being extremly flexible.
But I don't want to advertise any Perl, just hoping the idees behind
Moose can be helpful. So back to D.
The simplest property definition i can think of ist this:
class c {
public:
int a;
}
This can be interpreted as a property with name 'a' that has compiler
generated accessor functions int a(), and a (int) or int a(int) .The
compiler can not only auto generate them, it can also opimize them away.
So at the end of the day a field can be seen as an optimized property.
This implicates that i should be able to access fields using accessor
function syntax.
Yes, i really mean someting like x = c.a() or c.a( x) also for field
access. Even auto old = c.a( x) may be usefull. I think this can be
essential for templates or meta programming.
Syntax like x = c.a or c.a = x is cute but should be rewritten to the
above by the compiler and then optimized away in case of auto-generated
accessors.
The whole talk about using parentheses or not for accessor functions,
just to better distinguish accessors from real fields when reading D
sources i have a really simple solution for. Just conceptually get rid
of real fields in objects. Then we don't have to distinguish. And if
int a; in a class definition simply defines a lightweight rw property
that internally is implemented by the compiler as a field, we get the
benefits of real properties for each field without changing one line of
already written source code. The danger of confusing field access with a
function call omitting empty parentheses vanishes as well because every
field access is now consequently a call of a property accessor even when
optimized away. So function calls can safely omit empty parentheses
without being ambigious.
Then later we can think about creating a DSL that helps us to *declare*
more complex types of properties and have the compiler construct the
implicit parts at compile time. For instance i can think of a boolean
property that has a toggle accessor.
We shouldn't compose our classes from fields and functions that we
declare to be called with or without parentheses.
We should compose our classes from properties we declare (public, privat
or whatever) and let the compiler do the boring work for us.
Now to your problem with byLine:
Some said it should be stdin.byLine(), some others said it should be
stdin.byLine. They invoked contradictory rules that led to
Re: Short list with things to finish for D2
how about opLimit ?
