From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-25.smtpout.orange.fr [80.12.242.25]) by sourceware.org (Postfix) with ESMTPS id AD9723858C20 for ; Thu, 8 Jun 2023 12:38:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD9723858C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.16] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id 7EtzqYOviZnIG7Eu0qToe0; Thu, 08 Jun 2023 14:38:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1686227892; bh=qBrBdLwR963WSVVgYislACn+UsjKYFL68RP1JCYnay8=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=VUe2Xc6N1rIcKPsAyz3b4TTf+SDTu7tXtc/2iTsPJOM99mnypQcz6dKD38FeZTxRy ucUshzCiVRI8TV+Q4jKCv/oL8Ha+bb7E5KYD1RIqxFcPwD4wXnE0Mjb4Tp6xeYB9h9 8jvcNd6yZltjKe2Mplfb+xD6d7u4fLdAVEa+m+ZYHI6MLktA6an28CVMFTA6KSvwEY 2Aqn+UvDnhCmkEWV4hOxrfS98Zd/is+NuIdYBtg/9oDjE+TTjuEOqT8yplMhjxfqvz hy/3jd3i9zP2bDYheCVpNLk73YsCiCZyP1EPRiCXDwqv0SFHzNqhNQ0VcBiQdi+yiF 8Eq6uFg0sQuvw== X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Thu, 08 Jun 2023 14:38:12 +0200 X-ME-IP: 86.215.161.51 Message-ID: <74690341-bde3-47f2-8750-26a05578668d@orange.fr> Date: Thu, 8 Jun 2023 14:38:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 From: Mikael Morin Subject: Re: Possible funding of gfortran work To: Andre Vehreschild Cc: Damian Rouson , Thomas Koenig , Benson Muite , Jerry D , Paul Richard Thomas , GCC-Fortran-ML , Lexi Pimenidis , =?UTF-8?Q?Nicolas_K=c3=b6nig?= References: <4697f7be-ac3e-8c5d-f27c-3aec89b5b03f@protonmail.com> <0d923990-0b7a-a1ea-8389-bf3837e73ed0@gmail.com> <737bbf36-04a8-c1e4-b3aa-31121df66013@netcologne.de> <20230527132414.50184389@vepi2> <105c761a-5030-aee5-6587-2783a794f469@gmail.com> <20230530153242.54728d4d@vepi2> <2fa3240f-fbb8-23b6-2a10-24f9a415f729@netcologne.de> <5bde7c1f-3524-7f2e-fd48-a4b97734e2b9@emailplus.org> <2f95809c-8f0b-7d75-ca62-aeee11c6bee0@netcologne.de> <20230531142302.75ec742d@vepi2> <20230601111808.5ed7a9e3@vepi2> <20230605100825.78c4ac78@vepi2> <20230606150604.7cfbf6ac@vepi2> Content-Language: fr In-Reply-To: <20230606150604.7cfbf6ac@vepi2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WINNER_SUBJECT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. :-)