From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:4293:: with SMTP id i141-v6mr364076itb.18.1521174571707; Thu, 15 Mar 2018 21:29:31 -0700 (PDT) X-Received: by 2002:a9d:6005:: with SMTP id h5-v6mr22315otj.14.1521174571498; Thu, 15 Mar 2018 21:29:31 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer03.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!e10-v6no282298itf.0!news-out.google.com!h73-v6ni399itb.0!nntp.google.com!e10-v6no282296itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 15 Mar 2018 21:29:31 -0700 (PDT) In-Reply-To: <54953a97-f65a-4976-83ee-5b9d775bc503@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=87.116.179.50; posting-account=z-xFXQkAAABpEOAnT3LViyFXc8dmoW_p NNTP-Posting-Host: 87.116.179.50 References: <2e250363-97a3-45bd-948e-081e24d70655@googlegroups.com> <61dc87c3-30f1-4bbb-9125-89ec6e5dfc2e@googlegroups.com> <54953a97-f65a-4976-83ee-5b9d775bc503@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8fe01f65-dc65-47ee-8d24-ed4ee097aeb1@googlegroups.com> Subject: Re: GNAT corrupted builds with below second changes From: Bojan Bozovic Injection-Date: Fri, 16 Mar 2018 04:29:31 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5251 X-Received-Body-CRC: 807563785 Xref: reader02.eternal-september.org comp.lang.ada:51017 Date: 2018-03-15T21:29:31-07:00 List-Id: On Friday, March 16, 2018 at 4:27:46 AM UTC+1, Shark8 wrote: > On Thursday, March 15, 2018 at 1:59:21 PM UTC-6, Bojan Bozovic wrote: > >=20 > > Versioning file system is then what's needed, and that has been in VMS/= VAX-VMS/OpenVMS since seventies (and since seventies, VAX had 128 bit integ= ers as well). >=20 > I agree that a versioning FS is needed; but this only addresses the speci= fic issue raised here (the timestamp-resolution) and even a versioned FS is= inadequate to the general problem. >=20 > Take, for example, moving a file or directory and the impact that has on = a makefile/build-system: it invalidates the entire object in question and d= estroys the ability to build. -- As you can see, using the FS as an anemic = & ad-hoc DB is simply not addressing the entire problem. >=20 > > There's no good reason mainstream OS don't have it (like Windows, Linux= and OS X), it's absent only due to inertia. In linux there's NILFS but it'= s not used in mainstream distributions. DB is partial solution, as files be= long to the file system, not the database. >=20 > *sigh* -- Programs needn't BE files. >=20 > We could [and should] store them as parsed, processed semantically-valid = structures. (Yes, there *should* be an interface for import/export to files= /text; this operation could be done by the Types for the structure themselv= es as serialize/deserialize operations.) -- While it's possible these struc= tures could be stored in a mere file, that's not handling things very intel= ligently: if the above structure is suitable to being stored in a database = then [with a little cleverness] we inherit an entire entire system for deal= ing with ensuring that data is valid. >=20 > Yes, there's the ultra-trivial example of renaming -- pseudo-SQL: UPDATE = 'm' =3D 'MINIMUM' WHERE SCOPE =3D 'My_Function' -- which now won't have the= text-search and replace probleMINIMUM where there's extraneous replaceMINI= MUMents in coMINIMUMMINIMUMents and the like. >=20 > But that's a ridiculously simple/trivial example; what about something li= ke having the ability to make a subprogram generic with a simple command --= perhaps pseudo-SQL: INSERT Generic_Foo INTO 'Functions' WHERE SELECT x FRO= M 'Functions' WHERE x.Name =3D 'Some_Fn' REPLACING x.param['example'].type = WITH GENERIC_TYPE >=20 > Or something like that. (Of course these sorts of manipulations on the so= urce/DB should NOT be visible to the user, but are merely here to disabuse = you of the notion that all editing/manipulation must be done as text. [A bi= t ironic considering the text-based medium being used here.]) >=20 > Aside from all this, the usage of DBs can be a huge improvement to FS-bas= ed systems precisely because of properties of the DB. Take for example this= alternative to "Continuous Integration" from the mid 80s -- http://citesee= rx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.26.2533&rep=3Drep1&type=3Dpdf = -- by partitioning the project into workspaces and using a hierarchical dat= abase, only merging "upward" when everything on the "current level" is cons= istant [compilable], you end up with a DB where the root node *ALWAYS* has = "the last compilable version". (Combine that with versioning and you have a= record of EVERY COMPILING VERSION; *BAM!* no messed up/non-compiling crap = in your repository.) Of course you could implement any DB functionality in the file system, I do= n't deny, but it in fact should be system wide. Problem is the concept isn= 't marketable to non-technical users. I myself would use compiler which st= ores source in a DB, provided that copies on the FS exist, and I can pick t= he source that is to be used (DB or FS), and that it can be turned off for = source on removable media. In this era we have terabytes of disk space avai= lable anyway, duplication of space used isn't an issue.