This probably is a bug. Additionally this seems to also be missing the NSCF
callout as well.
> On Dec 26, 2015, at 10:46 PM, Luke Howard via swift-corelibs-dev
> wrote:
>
> In the implementation of getCString() in NSString.swift, it doesn’t appear to
> add the terminating NUL byte – is this a
In the implementation of getCString() in NSString.swift, it doesn’t appear to
add the terminating NUL byte – is this a bug or am I missing something?
— Luke
--
www.lukehoward.com
soundcloud.com/lukehoward___
swift-corelibs-dev mailing list
swift-corelib
Yea that seems to work on linux just fine. I made some more linux portability
corrections and it is now buildable on ubuntu 14.
> On Dec 26, 2015, at 8:15 PM, Luke Howard wrote:
>
>
>> On 27 Dec 2015, at 3:09 PM, Philippe Hausler wrote:
>>
>> So a few results so far from the linux side: I ra
> On 27 Dec 2015, at 3:09 PM, Philippe Hausler wrote:
>
> So a few results so far from the linux side: I ran across a few compiler
> crashes in the function metadataFromAccessorName; I need to dive a bit deeper
> into why it is failing.
> I have a few cross platform corrections that I will be
So a few results so far from the linux side: I ran across a few compiler
crashes in the function metadataFromAccessorName; I need to dive a bit deeper
into why it is failing.
I have a few cross platform corrections that I will be pushing shortly for you.
> On Dec 26, 2015, at 7:29 PM, Philippe H
I think what I might do to help get this ball rolling is actually create a
branch on the official repo; That way I can kick off CI etc on it.
> On Dec 26, 2015, at 7:09 PM, Luke Howard wrote:
>
>
>> On 27 Dec 2015, at 1:54 PM, Philippe Hausler wrote:
>>
>> It might be good for review side of
> On 27 Dec 2015, at 1:54 PM, Philippe Hausler wrote:
>
> It might be good for review side of things to break out those other issues
> into their own pull requests.
Agreed – I’ll do this soon.
— Luke
___
swift-corelibs-dev mailing list
swift-corelib
> I was looking over some of the init and encode methods you have, there are a
> few bits that might need some touch ups to match behavioral differences but I
> think I can probably merge in some of the work I have done as an addendum to
> what you have already gotten done.
Great, I just gave y
> On Dec 26, 2015, at 3:33 PM, Luke Howard wrote:
>
>
>> On 27 Dec 2015, at 3:45 AM, Philippe Hausler wrote:
>>
>> Totally reasonable since that is a limitation that will cause subclassers to
>> not be able to implement that even outside of Foundation.
>>
>> What would help most for unit te
> On 27 Dec 2015, at 3:45 AM, Philippe Hausler wrote:
>
> Totally reasonable since that is a limitation that will cause subclassers to
> not be able to implement that even outside of Foundation.
>
> What would help most for unit testing what you have so far?
>
> I have a few init?(coder:) imp
Totally reasonable since that is a limitation that will cause subclassers to
not be able to implement that even outside of Foundation.
What would help most for unit testing what you have so far?
I have a few init?(coder:) implementations that should match the
implementations on darwin; primaril
Another language thing I ran into – using classForKeyedArchiver/classForCoder
is impossible because declarations from extensions cannot be overridden yet.
For example I’d like to do:
internal class _NSCFString : NSMutableString {
…
override var classForCoder: AnyClass {
return NSMut
Thanks - also the encodeValueOfObjCType methods could have a nicer interface
(make the type an enum of Character, take Any instead of an unsafe pointer)...
Sent from my iPhone
> On 26 Dec 2015, at 05:46, Philippe Hausler wrote:
>
> Likely we will have to change that signature to instead of bei
Thanks - also the WithObjCType methods could have a nicer interface (make the
type an enum of Character, take Any instead of an unsafe pointer).
Sent from my iPhone
> On 26 Dec 2015, at 05:46, Philippe Hausler wrote:
>
> Likely we will have to change that signature to instead of being NSSet an
14 matches
Mail list logo
