qvto-dev http://dev.eclipse.org/mhonarc/lists/qvto-dev/maillist.html qvto-dev en-us Tue, 04 Jun 2013 10:50:04 GMT Tue, 04 Jun 2013 10:50:04 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) qvto-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/qvto-dev/maillist.html Re: [qvto-dev] Rampdown http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00053.html Hi looking at my expected participation in the next months, there is really nothing I can promise at this point as long as my personal future career is uncertain. Maybe the most reasonable role for me is to continue reporting/fixing legacy bugs. I still ha... Hi
looking at my expected participation in the next months, there is really nothing I can promise at this point as long as my personal future career is uncertain.

Maybe the most reasonable role for me is to continue reporting/fixing legacy bugs. I still have some pending reports in petto.


Regards
Christopher


----- Nachricht von ed@xxxxxxxxxxxxx ---------
     Datum: Fri, 31 May 2013 14:59:23 +0100
       Von: Ed Willink <ed@xxxxxxxxxxxxx>
   Betreff: Re: [qvto-dev] Rampdown
        An: Christopher Gerking <cgerking@xxxxxxxxxxxxx>


Hi Christopher

Welcome back. Perhaps you can give some indiction of your expected participation in the next few months so that the project can be co-ordinated.

You should be subscribed to the QVTo Buzilla Inbox so that you see all Bugzilla traffic. I leave it as an exercise for the student to search the QVTo RESOLVED's in the last two weeks to find the issue.

Since the code is now committed, reviewing is now a bit late to contribute to a change for Kepler, but reviewing is always good.

    Regards

        Ed



On 31/05/2013 12:43, Christopher Gerking wrote: 
Hi all,

I've finished my studies, creating maybe one of the most complex QVTo transformations ever.

@Ed: can you point me to the exact issue that is to be reviewed?

@Sergey: if you'd like to access my transformation for performance analysis: it is going to be publicly released in a few weeks.


Regards
Christopher



----- Nachricht von ed@xxxxxxxxxxxxx ---------
    Datum: Fri, 24 May 2013 13:44:45 +0100
      Von: Ed Willink <ed@xxxxxxxxxxxxx>
Antwort an: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
  Betreff: [qvto-dev] Rampdown
       An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>


   Hi Sergey

We're now in RampDown.

 *  After RC1[1]: At least 1 PMC member (typically, the Project Lead)
must review and vote + using the Bugzilla flag feature (see below).
 *  After RC2[2]: Another Committer from the component or project and
at least 1 PMC member must review and vote +1 after reviewing the bug
for appropriateness and risk.
 *  After RC3[3]: Two additional Committers and at least 2 PMC
members must review and vote +1 after reviewing the bug for
appropriateness and risk.

The above applies to functional code. Documentation and examples are
more relaxed; effectively use RC n-2 policies.

Even though I am/was a component co-lead, I'm not on the PMC, so
you'll need to get Kenn/Ed/... to approve any more commits.

Your latest patch looks fairly substantial, so it would be good to get
it reviewed.

Christopher: you were looking at trace issues; any chance?

   Regards

       Ed Willink


Links:
------
[1] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates
[2] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates
[3] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates


----- Ende der Nachricht von ed@xxxxxxxxxxxxx -----





-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6370 - Release Date: 05/30/13






----- Ende der Nachricht von ed@xxxxxxxxxxxxx -----




]]> Tue, 04 Jun 2013 10:45:07 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00053.html cgerking@xxxxxxx (Christopher Gerking) Re: [qvto-dev] Rampdown http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00052.html Hi Christopher,

Bug for review:   https://bugs.eclipse.org/bugs/show_bug.cgi?id=396538

Looking forward for transformations.

TIA,
  Sergey


On Fri, May 31, 2013 at 3:43 PM, Christopher Gerking <cgerking@xxxxxxxxxxxxx> wrote:
Hi all,

I've finished my studies, creating maybe one of the most complex QVTo transformations ever.

@Ed: can you point me to the exact issue that is to be reviewed?

@Sergey: if you'd like to access my transformation for performance analysis: it is going to be publicly released in a few weeks.


Regards
Christopher



----- Nachricht von ed@xxxxxxxxxxxxx ---------
     Datum: Fri, 24 May 2013 13:44:45 +0100
       Von: Ed Willink <ed@xxxxxxxxxxxxx>
Antwort an: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
   Betreff: [qvto-dev] Rampdown
        An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>



    Hi Sergey

We're now in RampDown.

  *  After RC1[1]: At least 1 PMC member (typically, the Project Lead)

must review and vote + using the Bugzilla flag feature (see below).
  *  After RC2[2]: Another Committer from the component or project and

at least 1 PMC member must review and vote +1 after reviewing the bug
for appropriateness and risk.
  *  After RC3[3]: Two additional Committers and at least 2 PMC

members must review and vote +1 after reviewing the bug for
appropriateness and risk.

The above applies to functional code. Documentation and examples are
more relaxed; effectively use RC n-2 policies.

Even though I am/was a component co-lead, I'm not on the PMC, so
you'll need to get Kenn/Ed/... to approve any more commits.

Your latest patch looks fairly substantial, so it would be good to get
it reviewed.

Christopher: you were looking at trace issues; any chance?

    Regards

        Ed Willink


Links:
------
[1] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates
[2] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates
[3] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates


----- Ende der Nachricht von ed@xxxxxxxxxxxxx -----



_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvto-dev

]]> Fri, 31 May 2013 14:04:18 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00052.html serg.boyko2011@xxxxxxx (Sergey Boyko) Re: [qvto-dev] Rampdown http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00051.html Hi all, I've finished my studies, creating maybe one of the most complex QVTo transformations ever. @Ed: can you point me to the exact issue that is to be reviewed? @Sergey: if you'd like to access my transformation for performance analysis: it is going to... Hi all,
I've finished my studies, creating maybe one of the most complex QVTo transformations ever.

@Ed: can you point me to the exact issue that is to be reviewed?

@Sergey: if you'd like to access my transformation for performance analysis: it is going to be publicly released in a few weeks.


Regards
Christopher



----- Nachricht von ed@xxxxxxxxxxxxx ---------
     Datum: Fri, 24 May 2013 13:44:45 +0100
       Von: Ed Willink <ed@xxxxxxxxxxxxx>
Antwort an: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
   Betreff: [qvto-dev] Rampdown
        An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>


    Hi Sergey

We're now in RampDown.

  *  After RC1[1]: At least 1 PMC member (typically, the Project Lead)
must review and vote + using the Bugzilla flag feature (see below).
  *  After RC2[2]: Another Committer from the component or project and
at least 1 PMC member must review and vote +1 after reviewing the bug
for appropriateness and risk.
  *  After RC3[3]: Two additional Committers and at least 2 PMC
members must review and vote +1 after reviewing the bug for
appropriateness and risk.

The above applies to functional code. Documentation and examples are
more relaxed; effectively use RC n-2 policies.

Even though I am/was a component co-lead, I'm not on the PMC, so
you'll need to get Kenn/Ed/... to approve any more commits.

Your latest patch looks fairly substantial, so it would be good to get
it reviewed.

Christopher: you were looking at trace issues; any chance?

    Regards

        Ed Willink


Links:
------
[1] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates
[2] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates
[3] http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates


----- Ende der Nachricht von ed@xxxxxxxxxxxxx -----




]]> Fri, 31 May 2013 11:43:28 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00051.html cgerking@xxxxxxx (Christopher Gerking) [qvto-dev] Rampdown http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00050.html Hi Sergey We're now in RampDown. After RC1: At least 1 PMC member (typically, the Project Lead) must review and vote + using the Bugzilla flag feature (see below). After RC2: Another Committer from the component or project and at least 1 PMC member must r... Hi Sergey

We're now in RampDown.
  • After RC1: At least 1 PMC member (typically, the Project Lead) must review and vote + using the Bugzilla flag feature (see below).
  • After RC2: Another Committer from the component or project and at least 1 PMC member must review and vote +1 after reviewing the bug for appropriateness and risk.
  • After RC3: Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk.
The above applies to functional code. Documentation and examples are more relaxed; effectively use RC n-2 policies.

Even though I am/was a component co-lead, I'm not on the PMC, so you'll need to get Kenn/Ed/... to approve any more commits.

Your latest patch looks fairly substantial, so it would be good to get it reviewed.

Christopher: you were looking at trace issues; any chance?

    Regards

        Ed Willink
]]> Fri, 24 May 2013 12:44:57 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00050.html ed@xxxxxxx (Ed Willink) [qvto-dev] Christopher Gerking has been declared to be an active committer http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00049.html modeling.mmt.qvt-oml Committers, Sergey Boyko has declared that Christopher Gerking (cgerking) is an active committer on this project. The reason for this declaration is: Patches were committed on behalf of Adolfo Sanchez-Barbudo Herrera. modeling.mmt.qvt-oml Committers, Sergey Boyko has declared that Christopher Gerking (cgerking) is an active committer on this project. The reason for this declaration is: Patches were committed on behalf of Adolfo Sanchez-Barbudo Herrera. ]]> Thu, 23 May 2013 17:01:01 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00049.html portal-noreply@xxxxxxx (portal on behalf of emo) Re: [qvto-dev] Hudson build limitations http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00048.html
Hi Ed,
 
Thank you for pointing to this!
It's indeed leads to more stable build process when all 'auto-generated' artifacts are delivered by a proven way.
 
Regards,
  Sergey


On Tue, May 21, 2013 at 9:39 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Sergey

In case you weren't aware, the Hudson Buckminster/GIT build has the following limitations compared to the old Athena/CVS build.

None of the OS-specific *.sh scripts are used. These variously generate grammars and documentation and so can be adequately performed by a developer and the resulting files committed to GIT, so I think there is no loss of functionality. You just need to commit products to GIT manually.

There may be other facilities around the edges that I missed. You're welcome to re-instate them.

    Regards

        Ed Willink
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvto-dev

]]> Wed, 22 May 2013 17:06:18 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00048.html serg.boyko2011@xxxxxxx (Sergey Boyko) Re: [qvto-dev] RC1 API problems http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00047.html &#xA0;I am using API tooling of course (IDE requires that) but some time ago I turned all API notifications into warnings (I don&#39;t remember the exact reason) and forget to restore.&#xA0; Thank you for pointing on that, I restored all notifications to defaults. ;As f...
Hi Ed,
 
Replies are in-lined below.
 
Regards,
 Sergey.
 


On Mon, May 20, 2013 at 10:32 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Sergey

You do not appear to be using API tooling for automated review, or team communication for peer review.
 
I am using API tooling of course (IDE requires that) but some time ago I turned all API notifications into warnings (I don't remember the exact reason) and forget to restore.  Thank you for pointing on that, I restored all notifications to defaults.
 
As for peer review I always wait for two weeks after I submit patch before commiting it to repository. So anyone who has spare time can take a look at it. Fortunately you finally took a look at sources and found API violations. Thank you.
 
 

When I refreshed my workspace I got 6 @since errors and one major version change needed.

The @since's are easy fixed. The major version needs an IQVTODebuggerShellExtension to host the new API.
 
Thank you once again. *Extension is an elegant way to extend interfaces but in costs of using 'instanceof'.
 

-----

I've also fixed a variety of old and new copyrights.
 
Oh, endless story with copyrights text. I see that is at least third patch on this topic.
 

-----

These are all available for review in the 'releng' branch that I shall push to master for build as RC1 tomorrow; assuming there are no howls of anguish.

    Regards

        Ed Willink
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvto-dev

]]> Wed, 22 May 2013 16:56:08 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00047.html serg.boyko2011@xxxxxxx (Sergey Boyko) Re: [qvto-dev] QVT* Debug test framework http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00046.html
Hi Ed,
 
I think you can look at the implementation of debug VM (QVTOVirtualMachine class). This is quite generic concept which is used both for QVTO workspace and remote debuggers.

QVTo debugger itself exploits QVTODebugEvaluator which simply extends QvtOperationalEvaluationVisitor with debug-specific events handling, lines information, etc.
Debugger is executed by means of QVTODebugTarget class which uses QVTOVirtualProcess and QVTOThread classes. It utilizes concept of request-response to interoperate with debug VM.

Workspace debugger is launched by QVTODebugConfiguration and remote debugger is launched by QVTOApplicationConfiguration.
All source code resides in 'org.eclipse.m2m.qvt.oml.debug.core' plug-in.
Debug UI plug-in 'org.eclipse.m2m.qvt.oml.debug.ui' contains UI aspects of debugging support: breakpoints, watch view, UI for debug launch configuration, etc.
 
Regards,
  Sergey.

 

 



On Sun, May 19, 2013 at 10:07 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Sergey

I notice some recent commits on debugging.

Now that we have QVTi CG going, I'm rethinking the order in which I write debuggers.

OCL is very troublesome since it has no natural activatiion, and validation wants to be in the invoking workspace, whereas QVTi is amenable to a simple remote activation.

So I now plan to do QVTi extensible to QVTc/QVTr as a conventional remote debugger then see how to localize the remote to support OCL vlidation debug later.

Any clues on bits of QVTo to look at exploit/what to rework to try to create something that is tailored for QVTo/QVTi/QVTc/QVTr/.... ?

    Regards

        Ed Willink


_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvto-dev

]]> Wed, 22 May 2013 16:35:13 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00046.html serg.boyko2011@xxxxxxx (Sergey Boyko) [qvto-dev] Hudson build limitations http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00045.html Hi Sergey In case you weren't aware, the Hudson Buckminster/GIT build has the following limitations compared to the old Athena/CVS build. None of the OS-specific *.sh scripts are used. These variously generate grammars and documentation and so can be adequ... Hi Sergey
In case you weren't aware, the Hudson Buckminster/GIT build has the following limitations compared to the old Athena/CVS build.

None of the OS-specific *.sh scripts are used. These variously generate grammars and documentation and so can be adequately performed by a developer and the resulting files committed to GIT, so I think there is no loss of functionality. You just need to commit products to GIT manually.

There may be other facilities around the edges that I missed. You're welcome to re-instate them.

    Regards

        Ed Willink

]]> Tue, 21 May 2013 05:39:14 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00045.html ed@xxxxxxx (Ed Willink) [qvto-dev] RC1 API problems http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00044.html Hi Sergey You do not appear to be using API tooling for automated review, or team communication for peer review. When I refreshed my workspace I got 6 @since errors and one major version change needed. The @since's are easy fixed. The major version needs a... Hi Sergey
You do not appear to be using API tooling for automated review, or team communication for peer review.

When I refreshed my workspace I got 6 @since errors and one major version change needed.

The @since's are easy fixed. The major version needs an IQVTODebuggerShellExtension to host the new API.

-----

I've also fixed a variety of old and new copyrights.

-----

These are all available for review in the 'releng' branch that I shall push to master for build as RC1 tomorrow; assuming there are no howls of anguish.

    Regards

        Ed Willink

]]> Mon, 20 May 2013 18:32:25 GMT http://dev.eclipse.org/mhonarc/lists/qvto-dev/msg00044.html ed@xxxxxxx (Ed Willink)