public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mikael Morin <morin-mikael@orange.fr>
To: Andre Vehreschild <vehre@gmx.de>
Cc: "Damian Rouson" <damian@archaeologic.codes>,
	"Thomas Koenig" <tkoenig@netcologne.de>,
	"Benson Muite" <benson_muite@emailplus.org>,
	"Jerry D" <jvdelisle2@gmail.com>,
	"Paul Richard Thomas" <paul.richard.thomas@gmail.com>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>,
	"Lexi Pimenidis" <lexi@badgersystems.de>,
	"Nicolas König" <koenigni@student.ethz.ch>
Subject: Re: Possible funding of gfortran work
Date: Thu, 8 Jun 2023 14:38:07 +0200	[thread overview]
Message-ID: <74690341-bde3-47f2-8750-26a05578668d@orange.fr> (raw)
In-Reply-To: <20230606150604.7cfbf6ac@vepi2>

Hello,

Le 06/06/2023 à 15:06, Andre Vehreschild a écrit :
> Hi Mikael,
> 
> ...
>> Yes, I don't like it but I understand the need for estimating.
>> I have looked at the evaluation criteria at [1]. There is among other
>> things:
>>> Furthermore, we look at how well the planning for the project is laid out.
>>> Are the activities well-structured, appropriate and feasible?
>>
>> I think we are far from having a "well laid out planning".  Even if it's
>> difficult to estimate the amount of days of work, we should probably at
>> least try to decompose the project into milestones, that is (small)
>> steps proving progress toward the target.
> 
> I understand. I would have been happy in the past when a client had as much
> knowledge and structure than we already have. Under "Project goal" we now have
> about 300 words. So we could add more.
Well, It wouldn't be really part of the goal, more how to reach that 
goal.  The "timeframe" question is possibly where it should go.  Or if 
you consider that the planning is a goal itself, it could be put here.

> What do you have in mind?
Something that breaks a big, risky thing to a set of smaller, manageable 
ones.  Something showing that the main problems (or some of them at 
least) have been identified and that we have a path to solve them one by 
one.

> Like adding
> more bullet points to each item in the form of:
>    - rebase existing implementation to current master
>    - identify missing requirements
>    - add tests for missing requirements
>    - implement missing requirements to pass tests.
>    ...
Well, this is a bit too general to be useful.

> Or are your targeting a more time based approach like:
>    Milestone 1: shared mem coarrays merge to master in week 2 of project
>    Milestone 2: finish research on general way for doing remote coarray access
>    in alien structures to finish in week 1 of project
>    ...
Maybe, but I would not emphasize the time constraints that much.

I have done it below for the scalarizer simplification, which is what 
for which the picture is the most clear in my mind regarding what to do 
and how to do it.
Here it is, with the expected number of weeks (that's 3 days for me) to 
do it:
  - Add optional scalarization block. (1 week)
  - Setup multiple expression usage (in case of multiple loops) in a 
more clear way. (3 weeks)
  - Move array and loop bounds setup to an opaque "start scalarization" 
function (3 weeks)
  - Make scalarization independant on previous setup of array 
information and move setup code from "start scalarization" to "finish 
scalarization" (5 weeks)
  - Initialize array information inside the gfc_conv_expr* functions and 
remove preliminary walking of expressions (4 weeks)

I hope that's not too technical to be put in the application form.

> 
> Take the above as examples please, not as proposals.
> 
> In the meantime I have added something to the "Who section":
...
> Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced in
>    gfortran development and component dependencies.
> 
I'm not affiliated to any company, university or organization.  Just 
myself. :-)



  reply	other threads:[~2023-06-08 12:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26  4:34 Jerry DeLisle
2023-05-26 17:09 ` Bernhard Reutner-Fischer
2023-05-26 21:22 ` Jerry D
2023-05-27  8:08   ` Thomas Koenig
2023-05-27 11:24     ` Andre Vehreschild
2023-05-27 16:19       ` Paul Richard Thomas
2023-05-28 14:26         ` Nicolas König
2023-05-28 15:07         ` Thomas Koenig
2023-05-28 19:25         ` Mikael Morin
2023-05-28 20:53           ` Jerry D
2023-05-30 13:32             ` Andre Vehreschild
2023-05-30 20:08               ` Thomas Koenig
2023-05-31  3:46                 ` Benson Muite
2023-05-31  6:08                   ` Thomas Koenig
2023-05-31  8:42                     ` Benson Muite
2023-05-31 12:23                     ` Andre Vehreschild
2023-05-31 14:08                       ` Damian Rouson
2023-06-01  9:18                         ` Andre Vehreschild
2023-06-01 10:56                           ` Bernhard Reutner-Fischer
2023-06-01 10:59                           ` Mikael Morin
2023-06-04  8:23                             ` Thomas Koenig
2023-06-05  8:08                             ` Andre Vehreschild
2023-06-05 11:44                               ` Mikael Morin
2023-06-06 13:06                                 ` Andre Vehreschild
2023-06-08 12:38                                   ` Mikael Morin [this message]
2023-06-14  8:28                                     ` Andre Vehreschild
2023-06-14  9:40                                       ` Mikael Morin
2023-06-14 18:48                                         ` Bernhard Reutner-Fischer
2023-06-01 11:12                           ` Benson Muite
2023-06-04  7:49                             ` Thomas Koenig
2023-06-05 10:12                               ` Andre Vehreschild
2023-06-05 10:07                             ` Andre Vehreschild
2023-06-05 12:16                               ` Thomas Koenig
2023-06-05 12:21                                 ` Andre Vehreschild
2023-06-08  5:34                               ` Benson Muite
2023-06-14  8:00                                 ` Andre Vehreschild
2023-06-02  0:53                           ` Jerry D
2023-06-05 10:09                             ` Andre Vehreschild

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74690341-bde3-47f2-8750-26a05578668d@orange.fr \
    --to=morin-mikael@orange.fr \
    --cc=benson_muite@emailplus.org \
    --cc=damian@archaeologic.codes \
    --cc=fortran@gcc.gnu.org \
    --cc=jvdelisle2@gmail.com \
    --cc=koenigni@student.ethz.ch \
    --cc=lexi@badgersystems.de \
    --cc=paul.richard.thomas@gmail.com \
    --cc=tkoenig@netcologne.de \
    --cc=vehre@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).