Le 2011-03-06 ? 17:51, Benjamin Shropshire a ?crit :

> On 03/06/2011 01:14 PM, Michel Fortin wrote:
>> Le 2011-03-06 ? 14:10, Don Clugston a ?crit :
>> 
>>> OTOH I don't know what to about the const(Object) ref pull request. That will definitely take a long time to evaluate.
>> Indeed, and I don't expect it to be integrated as fast as a normal pull request. It's fine for a more complicated patch to take longer to review. Don't hesitate to merge smaller ones first even if mine is older. Still, I hope someone looks at it eventually.
>> 
>> Also, this pull request is small relatively to what I'm preparing regarding integration of the Objective-C object model as extern(Objective-C). In a way you could say I'm testing the process with this smaller one first.
> 
> Given that we now have three(?) extern(Foo)'s in play (if not in the official version), should the API of what an extern looks like be formalised? Might it even be done so that unofficial support for other languages could be implemented as SO/DLL's without needing to rebuild dmd

Great idea. Unfortunately, it can't be done with DMD as we have now. For one thing, DMD would need to represent different linkage with different classes which could be registered dynamically at runtime, currently it uses a simple enum for that.

But to give you an idea of what I'm doing inside DMD: I had to change the backend a little so it can emit special Objective-C-reserved segments with custom alignment, I had to change the parser to add a new keyword (__selector) and a syntax for specifying selectors and even to parse the "extern(Objective-C)" construct, I had to make strings literals implicitly convertible to Objective-C's NSString literals and made some other type implicitly convert to equivalents, I had to make 'static' functions virtual functions belonging to the Objective-C metaclass (whether I should have invented a new keyword for that is debatable), I had to create an implicit nested class named "Class" in each class representing the metaclass and to add the built-in property "this.class" to access the metaclass, I had to implement dynamic casts of Objective-C objects, and a few other ticks like that.

The result of my work is starting to take shape. I'm currently a little stuck with memory management and finding a way to declare categories, but overall it's already starting to become usable. I made my first Cocoa test application last week.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On Mar 6, 2011 3:37 PM, "Michel Fortin" <michel.fortin at michelf.com> wrote:
>
> Le 2011-03-06 ? 17:51, Benjamin Shropshire a ?crit :
>
> > On 03/06/2011 01:14 PM, Michel Fortin wrote:
> >> Le 2011-03-06 ? 14:10, Don Clugston a ?crit :
> >>
> >>> OTOH I don't know what to about the const(Object) ref pull request. That will definitely take a long time to evaluate.
> >> Indeed, and I don't expect it to be integrated as fast as a normal pull
request. It's fine for a more complicated patch to take longer to review. Don't hesitate to merge smaller ones first even if mine is older. Still, I hope someone looks at it eventually.
> >>
> >> Also, this pull request is small relatively to what I'm preparing
regarding integration of the Objective-C object model as extern(Objective-C). In a way you could say I'm testing the process with this smaller one first.
> >
> > Given that we now have three(?) extern(Foo)'s in play (if not in the
official version), should the API of what an extern looks like be formalised? Might it even be done so that unofficial support for other languages could be implemented as SO/DLL's without needing to rebuild dmd
>
> Great idea. Unfortunately, it can't be done with DMD as we have now. For
one thing, DMD would need to represent different linkage with different classes which could be registered dynamically at runtime, currently it uses a simple enum for that.
>
> But to give you an idea of what I'm doing inside DMD: I had to change the
backend a little so it can emit special Objective-C-reserved segments with custom alignment, I had to change the parser to add a new keyword (__selector) and a syntax for specifying selectors and even to parse the "extern(Objective-C)" construct, I had to make strings literals implicitly convertible to Objective-C's NSString literals and made some other type implicitly convert to equivalents, I had to make 'static' functions virtual functions belonging to the Objective-C metaclass (whether I should have invented a new keyword for that is debatable), I had to create an implicit nested class named "Class" in each class representing the metaclass and to add the built-in property "this.class" to access the metaclass, I had to implement dynamic casts of Objective-C objects, and a few other ticks like that.
>

Aside from the parser changes, how much of that could be done with keyhole overrides (e.g. the name mangleing function and variable/member layout) and an extra set of augmentation passes (e.g. adding the nested Class and accessor)?

> The result of my work is starting to take shape. I'm currently a little
stuck with memory management and finding a way to declare categories, but overall it's already starting to become usable. I made my first Cocoa test application last week.
>
> --
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110307/7e343c5c/attachment.html>

On 6 mar 2011, at 20:10, Don Clugston wrote:

> On 6 March 2011 07:43, Walter Bright <walter at digitalmars.com> wrote:
>> I know, I know, but this piles up faster and faster. 8 new bugzilla reports just today. Many come with patches. I fixed one.
> 
> Does everyone know about github's Fork Queue? I think it is excellent.
> It is particularly great for cherry-picking commits.
> (Eg, if everything in a pull request is trivially correct, except one
> which needs more thought, use it to merge in everything except the
> difficult one.
> Takes just a few seconds).
> 
> Let's try to analyze the problem a bit more. Where is bottleneck,
> exactly? Linus Torvalds manages to merge an incredible number of
> patches per year.
> So I don't think the sheer number of patches themselves is the issue.


The process of the applying patches to the Linux kernel is, If I undertand it correctly, something like this:

1. First someone submits a patch for, let say, a network related problem
2. Then one of the kernel developers, that probably don't trust the person who submitted that patch and probably doesn't even know how it is, reviews the patch, applies it to his/her own repository of the kernel and tests it
3. The developer at step 2 ask another developer, above him/her, to pull from his/her repository
4. Now at this stage the second developer probably trusts the first developer but checks the code anyway and merges it with his/her own
5. Step 3-4 are repeated a couple of times and more code is added to the original pull request with other patches
6. Now Linus receives a pull request from one of the developers, probably the one responsibly for, in this example, the network related code or someone even higher up the hierarchy. This patch is probably just one among many other patches that Linus receives in the pull request and he doesn't care about this patch alone. He definitely doesn't trust the person how original submitted the patch and the first person who reviewed it but he trusts the person next to him, that he received the pull request from. The person Linus received the pull request doesn't either trust the original submitter but he trusts the person he received the pull request from and so on.
7. The next step for Linus just to merge, probably by now, this big pull request
8. If something goes wrong, any conflicts occurred while merge, Linus doesn't resolve them, he just say to the person he received the pull request form: "hey, I got a conflict when merging your pull request, fix it".
9. It then goes pack down the hierarchy to some level where someone fix the merge conflict and it all starts over

This is how I understand it after watching the Google talk Linus had about git.

-- 
/Jacob Carlborg

Le 2011-03-07 ? 10:14, Benjamin Shropshire a ?crit :

> On Mar 6, 2011 3:37 PM, "Michel Fortin" <michel.fortin at michelf.com> wrote:
>> 
>> But to give you an idea of what I'm doing inside DMD: I had to change the backend a little so it can emit special Objective-C-reserved segments with custom alignment, I had to change the parser to add a new keyword (__selector) and a syntax for specifying selectors and even to parse the "extern(Objective-C)" construct, I had to make strings literals implicitly convertible to Objective-C's NSString literals and made some other type implicitly convert to equivalents, I had to make 'static' functions virtual functions belonging to the Objective-C metaclass (whether I should have invented a new keyword for that is debatable), I had to create an implicit nested class named "Class" in each class representing the metaclass and to add the built-in property "this.class" to access the metaclass, I had to implement dynamic casts of Objective-C objects, and a few other ticks like that.
> 
> Aside from the parser changes, how much of that could be done with keyhole overrides (e.g. the name mangleing function and variable/member layout) and an extra set of augmentation passes (e.g. adding the nested Class and accessor)?

I don't think I could go very far with that. Look at all the files I touched up to now, it should give you an idea: <https://github.com/michelf/dmd/compare/f8ed1b3...d-objc>

The funny thing is that none of the above is really *required* to manipulate and create Objective-C objects. All you need is extern(C) to interact with the Objective-C runtime and some templates to make things easier and more type-safe. That's what I did with the D/Objective-C bridge. The problem is that it doesn't scale very well when you have large Objective-C APIs.
<http://michelf.com/weblog/2010/dobjc-dead-end-start-anew/>

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/