From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 6F5863840C2A for ; Mon, 4 Jan 2021 14:37:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F5863840C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mjambor@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 65BDEACBA; Mon, 4 Jan 2021 14:37:12 +0000 (UTC) From: Martin Jambor To: "Alper G." Cc: gcc@gcc.gnu.org Subject: Re: Google GSOC Idea In-Reply-To: References: User-Agent: Notmuch/0.31.2 (https://notmuchmail.org) Emacs/27.1 (x86_64-suse-linux-gnu) Date: Mon, 04 Jan 2021 15:37:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3033.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 14:37:14 -0000 Hi, On Sun, Dec 27 2020, Alper G. via Gcc wrote: > Hello, I am waiting for your suggestions and evaluations about an idea that > I am thinking about applying to this year's event of google gsoc. In short, > I can say about myself that I am an engineering student and worked on > compilers as well as several different fields. Nowadays, we see that > scripting languages such as javascript / typescript are more than just a > client-side language in the browser. In order to develop applications on > desktop and mobile devices, there are alternatives such as electron that > contain chromium and nodejs, have multi-disk-size requirements and cannot > be packaged statically before runtime, such as react-native. In order to > overcome such problems, it is necessary to create the ahead-of-time > compilation, which we are familiar with such as c / c ++, according to this > syntax and standards, and to call the graphics libraries and system calls > directly from within js. Therefore, I want to create a subset of gcc that > can be statically compiled and contains the ecmascript standards required > to run common js frameworks native. What are your comments on this > idea? I'm afraid I don't understand it at all. Making GCC "run common js frameworks" makes very little sense to me. Are you proposing some kind of JavaScript Front-end (which is not a JIT)? > What can we say about the acceptability for gsoc? Well, unfortunately I can say only that I do not understand it. If it is the JavaScript Front-end, the project would too big for a GSoC, by orders of magnitude, even if severely reduced in scope. Martin