Ronald Oussoren wrote:
>>1. Could we take the current bgen-generated C source and turn it over to
>>manual maintainers?
>
>There's little change that this will be accepted in the official tree.
Since the official Carbon tree is largely moribund anyway, I can't say I'm too
bothered by this. Henc
On 24-jun-2005, at 16:52, has wrote:
> Bob wrote:
>
>
>> Nobody is suggesting that we manually wrap Carbon.
>>
>
> Indeed. However, given the effective deadlock that bgen is causing
> (great-in-theory being the enemy of good-in-practice) perhaps we
> could find a pragmatic compromise? A semi-
On 24-jun-2005, at 17:05, has wrote:
> Ronald Oussoren wrote:
>
>
>> I'm not happy with the way that the Carbon wrappers work, adding
>> Carbon functions as methods of seemingly related classes. This
>> makes it harder to map documentation for Carbon to Python. It is
>> also ugly. But this
Ronald Oussoren wrote:
>I'm not happy with the way that the Carbon wrappers work, adding Carbon
>functions as methods of seemingly related classes. This makes it harder to map
>documentation for Carbon to Python. It is also ugly. But this might not be a
>problem with bgen itself.
>
>I'd prefer
Bob wrote:
>Nobody is suggesting that we manually wrap Carbon.
Indeed. However, given the effective deadlock that bgen is causing
(great-in-theory being the enemy of good-in-practice) perhaps we could find a
pragmatic compromise? A semi-automated system that works adequately would, I
think, be
On 24-jun-2005, at 15:27, Dethe Elza wrote:
> Ronald Oussoren wrote:
>
>
>> Someone with copious free time should build new Carbon wrappers, we
>> can than ask if the existing wrappers can be dropped in a future
>> version of Python. Sadly enough that probably is with python 2.6 at
>> the earlies
On 24-Jun-05, at 6:35 AM, Bob Ippolito wrote:
>> Is there a hitlist of frameworks that would be good to support,
>> but are not supported yet? What are some of the best targets for
>> someone who wants to jump in and help out?
>>
>
> The most useful work would be hacking on the parser/generato
On Jun 24, 2005, at 9:27 AM, Dethe Elza wrote:
> Ronald Oussoren wrote:
>
>
>> Someone with copious free time should build new Carbon wrappers, we
>> can than ask if the existing wrappers can be dropped in a future
>> version of Python. Sadly enough that probably is with python 2.6 at
>> the earl
Ronald Oussoren wrote:
> Someone with copious free time should build new Carbon wrappers, we
> can than ask if the existing wrappers can be dropped in a future
> version of Python. Sadly enough that probably is with python 2.6 at
> the earliest, which is a long way away.
>
Would there be any bene
On 24-jun-2005, at 12:22, Bob Ippolito wrote:
>>
>> Someone with copious free time should build new Carbon wrappers, we
>> can than ask if the existing wrappers can be dropped in a future
>> version of Python. Sadly enough that probably is with python 2.6 at
>> the earliest, which is a long way a
On Jun 24, 2005, at 6:13 AM, Ronald Oussoren wrote:
>
> On 24-jun-2005, at 12:03, Bob Ippolito wrote:
>
>
>>
>> On Jun 24, 2005, at 5:41 AM, Ronald Oussoren wrote:
>>
>>
>>
>>>
>>> On 24-jun-2005, at 0:52, has wrote:
>>>
>>>
>>>
>>>
Bob wrote:
>> Is there a way I
On 24-jun-2005, at 12:03, Bob Ippolito wrote:
>
> On Jun 24, 2005, at 5:41 AM, Ronald Oussoren wrote:
>
>
>>
>> On 24-jun-2005, at 0:52, has wrote:
>>
>>
>>
>>> Bob wrote:
>>>
>>>
>>>
>>>
> Is there a way I can contribute (using some of the time
> slots I now try to put aside for Boost an
On Jun 24, 2005, at 5:41 AM, Ronald Oussoren wrote:
>
> On 24-jun-2005, at 0:52, has wrote:
>
>
>> Bob wrote:
>>
>>
>>
Is there a way I can contribute (using some of the time
slots I now try to put aside for Boost and the unreasonable
number of
things I intend to do)?
>
On 24-jun-2005, at 0:52, has wrote:
Bob wrote:
Is there a way I can contribute (using some of the time
slots I now try to put aside for Boost and the unreasonable
number of
things I intend to do)?
Currently, all of the wrapped Carbon functionality is done with
an ancient, fragile an
Bob wrote:
>>Is there a way I can contribute (using some of the time
>>slots I now try to put aside for Boost and the unreasonable number of
>>things I intend to do)?
>
>Currently, all of the wrapped Carbon functionality is done with an ancient,
>fragile and undocumented parser/generator called
is a don't-write-broken-source-code kind
of issue, it can't happen by mixing things at runtime with Python.
>> From: Chinook <[EMAIL PROTECTED]>
>> Date: 21 juin 2005 18:20:07 HAEC
>> To: pythonmac-sig@python.org
>> Subject: Re: [Pythonmac-SIG] Finding what
pythonmac-sig@python.org
> Subject: Re: [Pythonmac-SIG] Finding what a broken alias refers to.
>
>
> On Jun 21, 2005, at 11:21 AM, Hubert Holin wrote:
>
>
>> For my first Python steps on the Mac, I am trying to find
>> information on all broken aliases in a folder
Hubert Holin wrote:
> It would seem that the best function to get that information is
>thru the FSFollowFinderAlias function of the Alias Manager, but
>unfortunately the only version which is wrapped is a member of the
>Alias class, which I have not found a way to use, as all I have is an
>ins
On Tue, 21 Jun 2005 11:21:17 -0400, Hubert Holin wrote
(in article <[EMAIL PROTECTED]>):
> Somewhere in the E.U., le 21/06/2005
>
> Bonjour
>
> For my first Python steps on the Mac, I am trying to find
> information on all broken aliases in a folder hierarchy (i.e. aliases
> which were
On Jun 21, 2005, at 11:21 AM, Hubert Holin wrote:
> For my first Python steps on the Mac, I am trying to find
> information on all broken aliases in a folder hierarchy (i.e. aliases
> which were created thru the Finder and which no longer reference an
> existing file or folder). While I am ab
Somewhere in the E.U., le 21/06/2005
Bonjour
For my first Python steps on the Mac, I am trying to find
information on all broken aliases in a folder hierarchy (i.e. aliases
which were created thru the Finder and which no longer reference an
existing file or folder). While I am able to
21 matches
Mail list logo
