Rakudo build broken as of parrot RELEASE_2_10_1-633-ga3ca6c8

[Jonathan Leto]

Howdy,

Whiteknight++ asks some good questions that we need to seriously think about.

I think a utility that reads HLL source code and then prints out a
list of deprecations
with links to deprecation pages would mostly solve this problem. I am
willing to help
hack on this.

We may also want to look into making something like
Package::DeprecationManager [0]
for Parrot.

Deprecations will always happen. We need to make it as easy as
possible for HLL devs
to understand and respond to them.

Duke

[0] http://search.cpan.org/dist/Package-DeprecationManager/

On Tue, Nov 30, 2010 at 4:10 PM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> Several functions were renamed by GCI students to help get TT #443.
> It's a deprecation item that has been eligible to be changed since
> 1.4.
>
> I'm not against keeping the old names around (as macros) to help ease
> the transition in theory. In practice, where do we draw the line?
> There has already been almost 2 years notice that the change would be
> coming. We've followed all the deprecation policy guidelines and
> waited plenty of time after eligibility to make these changes. How
> long do we need to keep exporting those names for the purpose of
> easing the transition? Forever?
>
> I'm not trying to be facetious, I really do want to know for future
> reference what people expect to happen when we make a C-level API
> change like this. There comes a point in the process when we need to
> stop offering the old function and start expecting people to be using
> the new version. Knowing when that point should be is going to be
> extremely important for us in the coming months, so we should figure
> it out now.
>
> I'm happy to put together a patch for Rakudo tonight. I can get
> started on that soon. I'm also happy to continue supporting the old
> name of this function as a macro if we have a clear plan for when such
> a duplicate should be offered and for exactly how long. Saying that
> we're going to backwards-support all C-level function interfaces
> forever is really not something I would support.
>
> The function in question has been renamed to
> Parrot_hll_get_ctx_HLL_namespace, for reference.
>
> --Andrew Whitworth
>
>
>
> On Tue, Nov 30, 2010 at 5:35 PM, Andy Dougherty <doughera at lafayette.edu> wrote:
>> Rakudo won't build with the current parrot master.  The first error
>> message is about the function 'Parrot_get_ctx_HLL_namespace'.  Were some
>> functions renamed?  If so, the old names should still be kept around as
>> wrappers for the new names, at least for a while.
>>
>> (Breakage like this makes it really hard to reliably bisect for important
>> changes.)
>>
>> --
>>    Andy Dougherty              doughera at lafayette.edu
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net