On Mon, Oct 13, 2014 at 11:29 AM, René Jansen <[email protected]> wrote:
> 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.
>
> Going back and removing this is an major impact at this point....and I
will NOT be the person doing the removal. And given that I anticipate that
5.0.0 is probably 6 months away from completion anyway, there is little
point in even making the attempt.
Rick
> 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
>
>
------------------------------------------------------------------------------
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
