Well, Rick, I think that is a slight overreaction to my remarks. I did not ask
to stop moving forward, just to do so in a fashion that causes less
fragmentation.
If namespaces break the linkage editor, the feature might be 15 years old, but
it is probably not used frequently enough to get the newness off of it. I
remember templates taking a very long time before they were fixed enough in
compiler infrastructure to not cause ballooning of executables - also in the
commercial IBM compilers, by the way. This might be something similar (let's
hope fixed more quickly though). How much does it hurt not to have namespaces
for say, half a year? - it is a code structuring feature, and I guess, a less
used one if it breaks widelly used tools.
So you are reacting to something I did not ask for. Please innovate, but let's
not innovate to end up with something that works on the latest Windows and a
handful of Linux versions, if there is an alternative.
best regards,
René.
On 13 okt. 2014, at 16:58, Rick McGuire <[email protected]> wrote:
>
>
> On Mon, Oct 13, 2014 at 10:45 AM, René Jansen <[email protected]> wrote:
> David,
>
> I appreciate the heads up, but I am wondering if this change does not come
> too soon. I know it is sometimes good to make a clean break, and a
> programming language is not a museum of older tools and architectures. Still,
> I am wondering if the subgoals - wanting to use modern building tools and
> modern compiler features, wanting an automated build procedure, are not
> counterproductive to the goal of wanting to reach the widest possible user
> segment - because it is the best possible programming language.
>
> My suggestion would be to put off the new features until the majority of
> platforms support them, or work actively to support alternative
> buiidling/compiling procedures. Cmake seems simple: don't use the modern
> features when older features do the job, or generate and tweak a makefile to
> perform this role.
>
> Frankly, if you are asking us to actually stop moving the language forward
> because of difficulties with older versions of the OS, then I will probably
> end my involvement with ooRexx entirely. In my we need to make more of a
> push to modernize the implementation and and add new features. If that's
> going to stop, then I see no need to even be involved any more.
>
> Rick
>
>
> I have bigger worries over compiler/linkage editor bugs. Features that
> trigger linkage editor bugs in widely used tools are clearly too new. I would
> postpone using those until most linkage editors are fixed. I think
> fragmenting the user base would be detrimental to language uptake. Other
> interpreters seem not to have this problem. If this is hard to fix, I would
> suggest to postpone the release until more infrastructure supports it. In my
> opinion, that would hurt ooRexx less than releasing for a smaller OS base.
>
> The feature causing the problem is Namespaces, which have been in the C++
> language for 15 years. Hardly qualifies as a feature that is "too new" to
> use.
>
> best regards,
>
> René Jansen.
>
> On 10 okt. 2014, at 18:15, David Ashley <[email protected]> wrote:
>
> > All -
> >
> > Please read all of this note as this could impact you.
> >
> > For the last few days I have been trying to get the 5.0.0 version of
> > ooRexx to build on my older VMs on the Build Machine. I keep running
> > into one of the following problems.
> >
> > 1. We use a lot of the newer features in CMake and these older operating
> > systems only have an older version of CMake available.
> >
> > 2. The GCC compiler/linker will not link the compiler output due to a
> > bug in the linker.
> >
> > Before I talk about these problem I want explain our philosophy on
> > building ooRexx. We supply many install packages for ooRexx for two
> > reasons: to verify that ooRexx will build on an OS release and to ensure
> > that ooRexx will install on an OS. We therefore try to impose as few
> > problems on the developer who wants to build ooRexx on their own.
> >
> > Starting with version 5.0.0 we have added a new wrinkle into building
> > ooRexx with the CMake product. While CMake is not usually installed by
> > default it is easily added using the OS specific installer or for
> > Windows, downloading it off the web.
> >
> > So now lets get back to our two problems.
> >
> > Problem 1 is not easy to solve for a developer. It usually means that
> > they will need to download the latest CMake source and build it for
> > themselves, which is not an easy task. That also means that I will have
> > to perform that task for each of our older operating systems (VMs).
> > There are over 25 of these so this task will take a LOT of time.
> >
> > Problem 2 is even worse. There is really no good solution for this. The
> > problem is caused by our choice to use newer C++ features to increase
> > the performance and ease of developing the interpreter. The only
> > solution would be to try and integrate a newer version of GCC into an OS
> > that may not be able to support it (no fun at all).
> >
> > For these reasons we will not be supporting ooRexx 5.0.0 on any of the
> > OSs that have problems 1 or 2. I know this is disappointing but please
> > try to be reassured that as time progresses this will become less of a
> > problem. Those using the older OSs will still be able to fall back on
> > ooRexx 4.2.0 (which is a really good version of ooRexx).
> >
> > Currently we are going to only support the OS versions that are showing
> > up on the nightly builds (plus some others that may be added later).
> >
> > If you have questions about this topic please feel free to post a reply
> > to this post.
> >
> > David Ashley
> >
> >
> > ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> > http://p.sf.net/sfu/Zoho
> > _______________________________________________
> > Oorexx-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho_______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
