[Liberty-eiffel] Summary of feedback about Macintosh proposal and rephra

> address@hidden hat am 16. Juni 2016 um 07:15 geschrieben:
>
>
> Send Liberty-eiffel mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Liberty-eiffel digest..."
>
>
> Today's Topics:
>
> 1. GitHub repository (Mehul Sanghvi)
> 2. Re: Request for feedback about proposed changes (Mehul Sanghvi)
> 3. Re: Request for feedback about proposed changes (Mehul Sanghvi)
> 4. Re: Bug #44601 (Mehul Sanghvi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 16 Jun 2016 00:54:02 -0400
> From: Mehul Sanghvi <address@hidden>
> To: address@hidden
> Subject: [Liberty-eiffel] GitHub repository
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> I notice that there is a GitHub repository as well as a Savanna repository.
> Which is the one to use ? I am not sure I have push access to the
> Savannah repository, but I can always create a pull-request on GitHub.
>
>
>
> cheers,
>
> mehul
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/liberty-eiffel/attachments/20160616/bb5010b9/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 16 Jun 2016 01:08:32 -0400
> From: Mehul Sanghvi <address@hidden>
> To: "Hans Zwakenberg | Ocean Consulting GmbH" <address@hidden>
> Cc: address@hidden
> Subject: Re: [Liberty-eiffel] Request for feedback about proposed
> changes
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> OSX is essentially an Unix variant. In looking at
> SYSTEM_TOOLS.system_list, I don't think we need to rename
> "macintosh_system" to be "osx_system". To me it makes more sense to let it
> be a UNIX system, and either Darwin or OS X / macOS as the flavour. I
> would prefer Darwin since that is the more appropriate name, with MacOS X /
> OSX / macOS all being more marketing names than anything else.
>
> Thinking in terms of "platforms", it makes more sense that
> "macintosh_system" in SYSTEM_TOOLS.system_list refers to MacOS 9 or older,
> and hence support for it should be removed rather than renamed to reflect
> the current marketing based name of the OS being used by Apple.
>
>
> cheers,
>
> mehul
>
>
>
> On Wed, Jun 15, 2016 at 4:02 PM, Hans Zwakenberg | Ocean Consulting GmbH <
> address@hidden> wrote:
>
> > Hi group (Mehul, especially for you too!),
> >
> > some of you might have noted that I've been working on removing support
> > for old legacy systems.
> >
> > In lieu of these acctivities I noted that Apple Inc. hasn't sold
> > 'Macintoshes' for quite a few years and since refers to them as 'Mac'. In
> > addition to this Apple sells a second group of mobile products. Basically,
> > software for their products are deployed on either OSX or IOS. For the
> > upcoming Curtiss release, I'd like to bring our configuration file in line
> > with this.
> > Unless any one of you has ligit objections, I'm going to rename the
> > current platform support 'OSX' instead of 'Macintosh'. If no objections
> > exist, this change is going to be committed to the current master-branch
> > early next week. All branches up to 'Bell' are _not_ going to be affected.
> >
> > A second issue I'd like to raise is the naming of the config file itself.
> > Liberty Eiffel has evolved a lot and has moved way beyond the legacy SE
> > compiler. The time has come that Liberty emancipates itself from the old
> > days and that we document this by using a consistent naming scheme across
> > platforms. Discussions with Rapha, Paolo and others gravitate towards
> > calling the configuration: 'liberty.conf'. As with our proposal above,
> > this change will be committed to the master-branch sometime next week,
> > unless ligit objections should exist. Again: the branches up to 'Bell'
> > will _not_ be affected.
> >
> > Regards,
> >
> > Hans
> >
> >
> >
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/liberty-eiffel/attachments/20160616/b6113143/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 16 Jun 2016 01:12:30 -0400
> From: Mehul Sanghvi <address@hidden>
> To: Cyril ADRIAN <address@hidden>
> Cc: "Hans Zwakenberg | Ocean Consulting GmbH"
> <address@hidden>, Eiffel <address@hidden>
> Subject: Re: [Liberty-eiffel] Request for feedback about proposed
> changes
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> I agree with Cyril, it makes more sense to have both .se and .conf for
> Curtiss, with a warning that .se is deprecated.
>
> On Wed, Jun 15, 2016 at 4:46 PM, Cyril ADRIAN <address@hidden>
> wrote:
>
> > Hi Hans,
> >
> > One potential issue I can think of when renaming liberty.se to
> > liberty.conf: most Liberty configuration files use the ".se" suffix as a
> > convention for configuration file (I think of loadpath.se, cecil.se?
> > others?) The source tree contains about 150 such files.
> >
> > Do you propose to rename all those files?
> >
> > Furthermore, how do you manage compatibility (people are bound to have
> > their own .se files)?
> >
> > Maybe Curtiss should allow both .se and .conf files, with a deprecation
> > warning.
> >
> > What do you think?
> >
> > Cheers,
> >
> > Cyril
> >
> >
> > 2016-06-15 22:02 GMT+02:00 Hans Zwakenberg | Ocean Consulting GmbH <
> > address@hidden>:
> >
> >> Hi group (Mehul, especially for you too!),
> >>
> >> some of you might have noted that I've been working on removing support
> >> for old legacy systems.
> >>
> >> In lieu of these acctivities I noted that Apple Inc. hasn't sold
> >> 'Macintoshes' for quite a few years and since refers to them as 'Mac'. In
> >> addition to this Apple sells a second group of mobile products. Basically,
> >> software for their products are deployed on either OSX or IOS. For the
> >> upcoming Curtiss release, I'd like to bring our configuration file in line
> >> with this.
> >> Unless any one of you has ligit objections, I'm going to rename the
> >> current platform support 'OSX' instead of 'Macintosh'. If no objections
> >> exist, this change is going to be committed to the current master-branch
> >> early next week. All branches up to 'Bell' are _not_ going to be affected.
> >>
> >> A second issue I'd like to raise is the naming of the config file
> >> itself. Liberty Eiffel has evolved a lot and has moved way beyond the
> >> legacy SE compiler. The time has come that Liberty emancipates itself from
> >> the old days and that we document this by using a consistent naming scheme
> >> across platforms. Discussions with Rapha, Paolo and others gravitate
> >> towards calling the configuration: 'liberty.conf'. As with our proposal
> >> above, this change will be committed to the master-branch sometime next
> >> week, unless ligit objections should exist. Again: the branches up to
> >> 'Bell' will _not_ be affected.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >
> >
> >
> > --
> > *Cyril ADRIAN*
> >
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/liberty-eiffel/attachments/20160616/329a08ec/attachment.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 16 Jun 2016 01:15:34 -0400
> From: Mehul Sanghvi <address@hidden>
> To: Cyril ADRIAN <address@hidden>
> Cc: Eiffel <address@hidden>
> Subject: Re: [Liberty-eiffel] Bug #44601
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Regarding running tests, I am doing the following:
>
> cd $LIBERTY_HOME
> se test --verbose --force test
>
> It has been running for a few hours now. I'm just going to let it run
> overnight.
>
> Lets see what results I get.
>
>
>
> On Wed, Jun 15, 2016 at 11:28 PM, Mehul Sanghvi <address@hidden>
> wrote:
>
> > I backtracked a little bit. I can now get bootstrap working on OSX using
> > the native gcc compiler. I am attaching two diffs to the email. The
> > diffs are against revision 64cad75 (git rev-parse --short HEAD).
> >
> > I have done this work on El Capitan. Can someone try out the patches on
> > an older system to see if they work ?
> >
> > I am planning on adding the following bugs (if they don't already exist):
> >
> > - Add support for *BSD systems
> >
> > - Add clang support
> >
> > - Rebrand from SmartEiffel to LibertyEiffel
> >
> > - Remove support for older compilers
> >
> > - Remove support for systems that are not being used.
> >
> > - Get BDWGC support to work on OSX. Currently it says that the GC is
> > old or missing. Also occurs on Debian/PPC.
> >
> > These are things I could think of, based on things people have mentioned
> > in this email thread. What sort of testing can I do to ensure that what I
> > have built is working correctly ? How do I run the tests in the test
> > directory ?
> >
> >
> > cheers,
> >
> > mehul
> >
> >
> > On Wed, Jun 15, 2016 at 7:13 PM, Mehul Sanghvi <address@hidden>
> > wrote:
> >
> >> I am presuming that after I check that I am going to have to re-generate
> >> the germ based on your earlier email in this thread, yes?
> >>
> >> On Wed, Jun 15, 2016 at 4:51 PM, Cyril ADRIAN <address@hidden>
> >> wrote:
> >>
> >>> The compiler is not equipped for clang. You may have missed something.
> >>>
> >>> Please have a look at the *SYSTEM_TOOLS*.*c_compiler_command* feature.
> >>>
> >>> Cheers,
> >>>
> >>> Cyril
> >>>
> >>> 2016-06-15 21:33 GMT+02:00 Mehul Sanghvi <address@hidden>:
> >>>
> >>>>
> >>>> I probably should have mentioned that I was writing in the context of
> >>>> bootstrapping and install.sh. I understand that compile_to_c by itself
> >>>> does nothing but generate C files.
> >>>>
> >>>> It seems that my resources/smarteiffel-germ may be bad. Here is what
> >>>> the file compile_to_c.make looks like after "T1: compile_to_c" is completed:
> >>>>
> >>>> % cat !$
> >>>> cat target/bin/compile_to_c.d/compile_to_c.make
> >>>> # Beginning of parallelizable section
> >>>> # End of parallelizable section
> >>>> clang -Xlinker compile_to_c1.o compile_to_c2.o compile_to_c3.o
> >>>> compile_to_c4.o compile_to_c5.o compile_to_c6.o compile_to_c7.o
> >>>> compile_to_c8.o compile_to_c9.o compile_to_c10.o compile_to_c11.o
> >>>> compile_to_c12.o compile_to_c13.o compile_to_c14.o compile_to_c15.o
> >>>> compile_to_c16.o compile_to_c17.o compile_to_c18.o compile_to_c19.o
> >>>> compile_to_c20.o compile_to_c21.o compile_to_c22.o compile_to_c23.o
> >>>> compile_to_c24.o compile_to_c25.o compile_to_c26.o compile_to_c27.o
> >>>> compile_to_c28.o compile_to_c29.o compile_to_c30.o compile_to_c31.o
> >>>> compile_to_c32.o compile_to_c33.o compile_to_c34.o compile_to_c35.o
> >>>> compile_to_c36.o compile_to_c37.o compile_to_c38.o compile_to_c39.o
> >>>> compile_to_c40.o compile_to_c41.o compile_to_c42.o compile_to_c43.o
> >>>> compile_to_c44.o compile_to_c45.o compile_to_c46.o compile_to_c47.o
> >>>> compile_to_c48.o compile_to_c49.o compile_to_c50.o compile_to_c51.o
> >>>> compile_to_c52.o compile_to_c53.o compile_to_c54.o compile_to_c55.o
> >>>> compile_to_c56.o compile_to_c57.o compile_to_c58.o compile_to_c59.o
> >>>> compile_to_c60.o compile_to_c61.o compile_to_c62.o compile_to_c63.o
> >>>> compile_to_c64.o compile_to_c65.o compile_to_c66.o compile_to_c67.o
> >>>> compile_to_c68.o compile_to_c69.o compile_to_c70.o compile_to_c71.o
> >>>> compile_to_c72.o compile_to_c73.o compile_to_c74.o compile_to_c75.o
> >>>> compile_to_c76.o compile_to_c77.o compile_to_c78.o compile_to_c79.o
> >>>> compile_to_c80.o compile_to_c81.o compile_to_c82.o compile_to_c83.o
> >>>> compile_to_c84.o compile_to_c85.o compile_to_c86.o compile_to_c87.o
> >>>> compile_to_c88.o compile_to_c89.o compile_to_c90.o compile_to_c91.o
> >>>> compile_to_c92.o compile_to_c93.o compile_to_c94.o compile_to_c95.o
> >>>> compile_to_c96.o compile_to_c97.o compile_to_c98.o compile_to_c99.o
> >>>> compile_to_c100.o compile_to_c101.o compile_to_c102.o compile_to_c103.o
> >>>> compile_to_c104.o compile_to_c105.o compile_to_c106.o compile_to_c107.o
> >>>> compile_to_c108.o compile_to_c109.o compile_to_c110.o compile_to_c111.o
> >>>> compile_to_c112.o compile_to_c113.o compile_to_c114.o compile_to_c115.o
> >>>> compile_to_c116.o compile_to_c117.o compile_to_c118.o compile_to_c119.o
> >>>> compile_to_c120.o compile_to_c121.o compile_to_c122.o compile_to_c123.o
> >>>> compile_to_c124.o compile_to_c125.o compile_to_c126.o compile_to_c127.o
> >>>> compile_to_c128.o compile_to_c129.o compile_to_c130.o compile_to_c131.o
> >>>> compile_to_c132.o compile_to_c133.o compile_to_c134.o compile_to_c135.o -x
> >>>> none
> >>>> strip compile_to_c.new
> >>>>
> >>>>
> >>>>
> >>>> Notice that there are no files to compile ?!!!! Also notice that
> >>>> there is no "-o compile_to_c.new" option provided after the "-Xlinker"
> >>>> option. This is not the case on a Linux build. install.sh uses a while
> >>>> loop to process
> >>>>
> >>>> What actions have taken place up to this point in the install.sh?
> >>>>
> >>>> 1. Created ~/.config/liberty-eiffel link
> >>>> 2. Created target/bin/compile_to_c.d
> >>>> 3. cd resources/smarteiffel-germ
> >>>> 4. process compile_to_c.make file and run the commands in it.
> >>>> rename a.out to compile_to_c
> >>>> 5. copy everything from resources/smarteiffel-germ to
> >>>> target/bin/compile_to_c.d
> >>>> 6. cd target/bin/compile_to_c.d
> >>>> 7. T1 compile_to_c begins by doing ./compile_to_c -verbose -boost
> >>>> -no_gc compile_to_c -o compile_to_c.new
> >>>> 8. examine target/bin/compile_to_c.d/compile_to_c.make to get the
> >>>> result above.
> >>>>
> >>>>
> >>>> This to me would indicate there is something not right in the germ.
> >>>> Would that be a correct assumption ? Or maybe the process by which I got
> >>>> the germ, based on earlier email in this thread, was not followed correctly
> >>>> ?
> >>>>
> >>>> If it is something wrong with the germ, where would I start to track it
> >>>> down and how can I identify it ? I tried looking at
> >>>> src/smarteiffel/commands/compile_to_c.e but not knowing Eiffel just yet, it
> >>>> doesn't make much sense to me. Apart from the argument parsing loop.
> >>>>
> >>>>
> >>>>
> >>>> cheers,
> >>>>
> >>>> mehul
> >>>>
> >>>>
> >>>> On Wed, Jun 15, 2016 at 1:02 PM, Cyril ADRIAN <address@hidden>
> >>>> wrote:
> >>>>
> >>>>> As I said, compile_to_c produces C files. It also produces C header
> >>>>> files, and everything needed for the C compilation proper.
> >>>>> As you found out, it also produces a .make file. But it does nothing
> >>>>> to "execute" that file.
> >>>>>
> >>>>> The files produced by compile_to_c are usually used by the "compile"
> >>>>> tool, which produces the executable file using the .make file as starting
> >>>>> point.
> >>>>>
> >>>>> The thing is, when bootstrapping, "compile" does not exist. It is
> >>>>> built later.
> >>>>>
> >>>>> To summarize:
> >>>>>
> >>>>> - Nominally, the tool chain is: se -> compile -> compile_to_c
> >>>>>
> >>>>> - BUT, when bootstrapping, compile_to_c is the only "germ", it is
> >>>>> enough to build all the other tools; but the C compilation must be
> >>>>> performed by hand, using the .make file. Since you are perusing install.sh
> >>>>> you should be able to find out how this is performed in T1 and T2.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Cyril
> >>>>>
> >>>>>
> >>>>> 2016-06-15 18:22 GMT+02:00 Mehul Sanghvi <address@hidden>:
> >>>>>
> >>>>>> I am confused. I understand what compile_to_c does and what it is
> >>>>>> used for. Yet in the install.sh we have code that is
> >>>>>> expecting compile_to_c.new, in the "Bootstrapping SmartEiffel Tools"
> >>>>>> section, for T1 and T2.
> >>>>>>
> >>>>>> According to the "-help" output of ./compile_to_c:
> >>>>>>
> >>>>>> -o <file> Put the executable program into <file>
> >>>>>>
> >>>>>>
> >>>>>> And that is exactly what it does. The compile_to_c.make file that is
> >>>>>> created, will have a line in it like the following:
> >>>>>>
> >>>>>> gcc -pipe -O2 -c -x c compile_to_c1.c
> >>>>>> # End of parallelizable section
> >>>>>> gcc -Xlinker -no-as-needed -o compile_to_c.new compile_to_c1.o
> >>>>>> compile_to_c2.o ...
> >>>>>> strip compile_to_c.new
> >>>>>>
> >>>>>>
> >>>>>> So -o is used and the name of the given executable is used in the
> >>>>>> strip command as well. I got this based on looking at
> >>>>>> what happens on a Linux system. Its an old 400MHz PowerPC based G4
> >>>>>> PowerMac running Debian. The builds take an
> >>>>>> extremely long time, but I am able to observe things a little better
> >>>>>> while the build is going on. :) Sometimes slow and old is good.
> >>>>>>
> >>>>>>
> >>>>>> When I look at the compile_to_c.make that I have, I don't even have
> >>>>>> anything for parallelisation. Just the linking line, and even that is
> >>>>>> without the -o option. So I have a bug somewhere in the germ I've created
> >>>>>> and will have to track it down.
> >>>>>>
> >>>>>>
> >>>>>> Comments ? Thoughts ? Suggestions ?
> >>>>>>
> >>>>>> I think I feel a little less confused now that I have seen what the
> >>>>>> Linux build is doing.
> >>>>>>
> >>>>>>
> >>>>>> cheers,
> >>>>>>
> >>>>>> mehul
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jun 15, 2016 at 9:59 AM, Cyril ADRIAN <address@hidden
> >>>>>> > wrote:
> >>>>>>
> >>>>>>> Mehul,
> >>>>>>>
> >>>>>>> compile_to_c produces C files, not binaries. Those files must be
> >>>>>>> compiled by a C compiler to produce the actual executable file.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Cyril
> >>>>>>>
> >>>>>>> 2016-06-15 15:32 GMT+02:00 Mehul Sanghvi <address@hidden>:
> >>>>>>>
> >>>>>>>> So I do the following:
> >>>>>>>>
> >>>>>>>> cd target/bin/compile_to_c.d
> >>>>>>>> ./compile_to_c -verbose -boost -no_gc compile_to_c -o
> >>>>>>>> compile_to_c.new
> >>>>>>>>
> >>>>>>>> And there is no compile_to_c.new binary generated. I am guessing
> >>>>>>>> it should be in the same directory where
> >>>>>>>> I am running the command. Or not ?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> cheers,
> >>>>>>>>
> >>>>>>>> mehul
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Jun 13, 2016 at 10:16 PM, Mehul Sanghvi <
> >>>>>>>> address@hidden> wrote:
> >>>>>>>>
> >>>>>>>>> Yes that did the trick. I was able to get a new germ which has
> >>>>>>>>> support for clang on OSX/Darwin/macOS.
> >>>>>>>>>
> >>>>>>>>> The problem I am running into now is that when I run install.sh I
> >>>>>>>>> am not getting a "compile_to_c.new" generated but the following:
> >>>>>>>>>
> >>>>>>>>> progress 30 1 $MAXTOOLCOUNT "T1: compile_to_c"
> >>>>>>>>> run ./compile_to_c -verbose -boost -no_gc compile_to_c -o
> >>>>>>>>> compile_to_c.new
> >>>>>>>>>
> >>>>>>>>> I have tried running the command manually and it is no different
> >>>>>>>>> from when being run in the script.
> >>>>>>>>>
> >>>>>>>>> The below are results I see before the command completes:
> >>>>>>>>>
> >>>>>>>>> Total Number of "inspect" used for Dynamic dispatch: 9129
> >>>>>>>>> Total Number of Merged "when" clauses (cumulated): 5097
> >>>>>>>>> Assignment graph: 659 nodes and 2012 transitions.
> >>>>>>>>> FEATURE_STAMPs total number = 5920
> >>>>>>>>> FEATURE_STAMPs with rename = 39
> >>>>>>>>> Total time spent in parser: 00:00.705835
> >>>>>>>>> Total time spent getting started: 00:00.174095
> >>>>>>>>> Total time spent specializing one type: 00:14.933290
> >>>>>>>>> Total time spent specializing and checking: 00:11.650085
> >>>>>>>>> Total time spent collecting features: 00:00.695697
> >>>>>>>>> Total time spent inlining dynamic dispatch: 00:01.146237
> >>>>>>>>> Total time spent simplifying: 00:03.118921
> >>>>>>>>> Total time spent adapting features: 00:00.222636
> >>>>>>>>> Total time spent safety checking: 00:00.000058
> >>>>>>>>> Type-system safety check not performed in this mode
> >>>>>>>>> (use the -safety_check flag).
> >>>>>>>>> Done.
> >>>>>>>>> Writing "compile_to_c.id" file.
> >>>>>>>>> Aliased STRINGs: 58923.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The log file does not have anything that indicates any issues.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thoughts, suggestions ?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> cheers,
> >>>>>>>>>
> >>>>>>>>> mehul
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Jun 13, 2016 at 2:49 PM, Raphael Mack <
> >>>>>>>>> address@hidden> wrote:
> >>>>>>>>>
> >>>>>>>>>> Am Montag, den 13.06.2016, 10:11 -0400 schrieb Mehul Sanghvi:
> >>>>>>>>>> >
> >>>>>>>>>> > Yes that is true.
> >>>>>>>>>> >
> >>>>>>>>>> >
> >>>>>>>>>> > Let me re-compile that again. I had run make-germ.sh and it had
> >>>>>>>>>> > deleted resources/smarteiffel-germ/*.c but nothing that a "git
> >>>>>>>>>> pull"
> >>>>>>>>>> > can not fix.
> >>>>>>>>>> >
> >>>>>>>>>> >
> >>>>>>>>>> > Any other options that I need to be using when compiling
> >>>>>>>>>> compile_2_c
> >>>>>>>>>> > and generating the germ with clang support ?
> >>>>>>>>>>
> >>>>>>>>>> -boost -no_gc
> >>>>>>>>>>
> >>>>>>>>>> should be sufficient. The interesting question is, whether we need
> >>>>>>>>>> special handling for clang or whether it is sufficiently
> >>>>>>>>>> compatible to
> >>>>>>>>>> gcc. - But you'll find out and, as the germ code already compiles
> >>>>>>>>>> it
> >>>>>>>>>> looks good in my eyes.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> Rapha
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Mehul N. Sanghvi
> >>>>>>>>> email: address@hidden
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Mehul N. Sanghvi
> >>>>>>>> email: address@hidden
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> *Cyril ADRIAN*
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Mehul N. Sanghvi
> >>>>>> email: address@hidden
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *Cyril ADRIAN*
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Mehul N. Sanghvi
> >>>> email: address@hidden
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> *Cyril ADRIAN*
> >>>
> >>
> >>
> >>
> >> --
> >> Mehul N. Sanghvi
> >> email: address@hidden
> >>
> >
> >
> >
> > --
> > Mehul N. Sanghvi
> > email: address@hidden
> >
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/liberty-eiffel/attachments/20160616/3ae5d72f/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Liberty-eiffel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/liberty-eiffel
>
>
> ------------------------------
>
> End of Liberty-eiffel Digest, Vol 29, Issue 21
> **********************************************
>

From:	Hans Zwakenberg \| Ocean Consulting GmbH
Subject:	[Liberty-eiffel] Summary of feedback about Macintosh proposal and rephrasing thereof.
Date:	Thu, 16 Jun 2016 16:57:26 +0200 (CEST)