http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #80 from nfxjfg@gmail.com 2010-09-16 11:26:43 PDT ---
By the way, if the patch is going to be accepted, it would probably be good to get rid of the NO_SCAN flags. Instead, NO_SCAN should be detected by examining the PointerMap. A PointerMap with length 0 could take over the NO_SCAN meaning.

E.g.:

Old code:
bool is_NO_SCAN = !(typeinfo.flags() & 1);

New code:
bool is_NO_SCAN = typeinfo.pointermap().bits.length == 0;

Then you don't need to provide/pass around the TypeInfo.flags() anymore. Would get rid of some uglyness.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #81 from nfxjfg@gmail.com 2010-11-14 18:06:05 PST ---
I obsoleted all the patches because they were outdated (too old dmd/Tango versions). I don't think it's very efficient to make new patches and post them here (I mean, there are already 21 obsoleted patches, and this issue has probably the most comments on bugzilla, despite not much going on).

Please send me an email to request newer patches. These patches include:
* dmd patch for PointerMap output (backwards compatible to old Phobos etc.)
* Tango patch to include PointerMap in object.d, and to make use of them in
gcx.d
* additional dmd patch to make associative array scanning precise (changes ABI
to include more type info; again completely backwards compatible to Phobos)
* additional Tano patch to make associative array scanning precise (backwards
compatible)

The obsoleted patches will only apply to old dmd versions, and what's worse, only if you run unix2dos on all dmd source files beforehand. (The line endings in the dmd.zip are inconsistent, and the dmd svn is unusable because releases are not tagged properly.)

Btw. I didn't really appreciate Walter's 64 bit changes to the AA ABI. Really, the ABI should pass all TypeInfos to the AA functions. If my patch is applied, dmd supports roughly 3 AA ABIs, which is very silly.

If someone has a better idea how to keep track of the patches and so on (that are better than flooding bugzilla or emailing me), please make a suggestions.

Last but not least:

[02:55:20] <wm4> AndreiAlexandres: also, I'm about to post new patches for precise gc scanning (update to newer dmd versions) to issue 2463 on bugzilla; is there some better way to participate on D/dmd development than to continuously post patches to bugzilla that are going to be ignored [02:57:07] * AndreiAlexandres has quit (Quit: AndreiAlexandres)

It could be a bad coincidence, or show how fabulously awesome the D development model is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #82 from Leandro Lucarella <llucax@gmail.com> 2010-11-14 19:17:59 PST ---
Maybe you should try with LDC's or GDC's issues trackers, as this is an implementation detail maybe it gets better reception there (but it would be hard to get accepted there since both uses DMDFE and it would mean to fork it).

When I want to keep patches easily updated I use git (git svn in this case). But then, the lack of tagging in DMD's svn can be annoying.

Anyway, unfortunately DMD development model still sucks, it sucks much less than... let's say 2 years ago, but...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #83 from bearophile_hugs@eml.cc 2010-11-15 04:43:23 PST ---
(In reply to comment #82)

> Anyway, unfortunately DMD development model still sucks, it sucks much less than... let's say 2 years ago, but...

Walter is willing to slowly improve his practices. Do you have a list of suggestions? If you show this list on the main D newsgroup he might pick something from it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #84 from Leandro Lucarella <llucax@gmail.com> 2010-11-15 04:47:48 PST ---
(In reply to comment #83)
> (In reply to comment #82)
> 
> > Anyway, unfortunately DMD development model still sucks, it sucks much less than... let's say 2 years ago, but...
> 
> Walter is willing to slowly improve his practices. Do you have a list of suggestions? If you show this list on the main D newsgroup he might pick something from it.

I (and others) already suggested him how to improve things, a few really basic examples that come to my mind right now:

* Tag releases in svn
* Give feedback to people wanting to contribute

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #85 from bearophile_hugs@eml.cc 2010-11-15 09:33:56 PST ---
(In reply to comment #84)

> I (and others) already suggested him how to improve things,

Keep suggesting those things. Sometimes you have to say something five times to Walter.


> * Tag releases in svn

Explain him why this is useful.


> * Give feedback to people wanting to contribute

Maybe he doesn't fully understand why contributions from other people are important. Showing him some examples is useful.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #86 from Leandro Lucarella <llucax@gmail.com> 2010-11-15 09:44:18 PST ---
(In reply to comment #85)
> (In reply to comment #84)
> 
> > I (and others) already suggested him how to improve things,
> 
> Keep suggesting those things. Sometimes you have to say something five times to Walter.
> 
> 
> > * Tag releases in svn
> 
> Explain him why this is useful.
> 
> 
> > * Give feedback to people wanting to contribute
> 
> Maybe he doesn't fully understand why contributions from other people are important. Showing him some examples is useful.

This is getting a little off-topic here, but I think I'll focus on other projects, is too much effort. I agree that Walter has improved a little, but the ratio results/efforts is *really* low still, and it doesn't worth it for me any more. I hate sounding like a broken record...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #87 from Walter Bright <bugzilla@digitalmars.com> 2011-04-13 21:51:35 PDT ---
The idea, as I understand it, is to supply a bit mask of where the pointers are. For me, the difficulties are:

1. distinguishing real pointers from might-be-a-pointer (such as you might get from union { int a; void* p; }).

2. large static arrays, large structs/classes, structs with large static array members, etc.

The amount of static data dedicated to such bit arrays could get very large.

I see two solutions:

1. if it is case (1) or (2), give up for that type and revert to the current
method of scanning that object

2. devise a 'state machine' instead that the gc executes for a type. The state machine has instructions like "advance n bytes to the next pointer" and "the next pointer is ambiguous" and "execute the following sequence n times."

I don't see an obvious choice which is better.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #88 from bearophile_hugs@eml.cc 2011-04-14 02:06:33 PDT ---
(In reply to comment #87)

> 1. distinguishing real pointers from might-be-a-pointer (such as you might get from union { int a; void* p; }).

In C unions are not tagged, but in many C programs the programmer has introduced some mean to tell apart at runtime what's inside the union, like a first bit set in the pointer, a tag field in a struct where the union is, or a tag value elsewhere in the program. So time ago I have suggested an optional standard method useful fur unions, named something like onGC(...). It gets called at runtime by the GC during when it scans the union instance, and in some way tells the GC if a field is a pointer to follow (to call that onGC() the GC has to know that something is a specific union in the first place).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #89 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 02:23:28 PDT ---
(In reply to comment #88)

In order to support C compatibility, untagged unions must be supported by the type system and the GC.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------