Re: [swift-corelibs-dev] [swift-evolution] [Discussion] Resources

[Karl Wagner via swift-corelibs-dev]

> On 27. Sep 2017, at 12:32, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
> 
>> On 25. Sep 2017, at 18:54, Rick Ballard via swift-evolution 
>>  wrote:
>> 
>> Hi Karl and Keith,
>> 
>> (+ swift-build-dev and swift-corelibs-dev)
>> 
>> The SwiftPM core team has had some preliminary discussions already with the 
>> swift-corelibs team about the best way to support resources; whatever we do 
>> here will likely be a collaboration between SwiftPM and Foundation. We're 
>> currently defining our roadmap for SwiftPM in Swift 5, and it's not clear 
>> yet whether resource support will fit into this year or not, but either way 
>> it's clearly something we'll want to do. We're looking to encourage a 
>> thriving developer community around the Swift package manager, and we know 
>> that this will be important for many uses. If there are other limitations 
>> that are currently holding people back, we'd welcome feedback (and 
>> contributions!).
>> 
>> While we're not actively working on a proposal for resource support at the 
>> moment, if you have particular thoughts, please feel free to share them, 
>> possibly cross-posted between swift-build-dev, swift-corelibs-dev, and 
>> swift-evolution.
>> 
>> Cheers,
>> 
>>  - Rick
>> 
> 
> Thanks Rick, that’s very interesting.
> 
> I have been bouncing some ideas around my head about how to incorporate 
> external resource files as first-class “source” elements of a Swift 
> application (similar to the “resource literals” and “image literals” that we 
> have for Xcode integration).
> 
> Android has the “R” system, which generates resource-ids for things like 
> image and layout-xml resources. I don’t know if that’s a common system used 
> by a lot of platforms, but I first encountered it with Android and it has 
> some features I really like (like compile-time checking that resources 
> exist). I’ve recently been using the “R.Swift” library [1] after a 
> colleague's recommendation, which generates a similar-style interface for 
> Swift projects, and I think that’s also pretty nifty. It improves on the 
> Android system by properly-typing things like image and layout resources 
> (Android reduces them all to integer IDs). I could imagine something like 
> that either built-in to Swift itself, or as a component of SwiftPM.
> 
> We would also need some substantial runtime support. Apple’s platforms 
> introduce resource variations for different devices, localisations, screen 
> densities, colour profiles, etc - and that’s why they have their own “asset 
> catalog” format; to manage all of that complexity. A good cross-platform 
> resources abstraction would need to match that and include some way for each 
> platform to resolve its ideal variation of the resource.
> 
> There are times when rich assets belong below the UI layer. For example, I’m 
> creating a cross-platform SDK for a large company with multiple subsidiary 
> brands. The branding assets are specific in contracts between us and 
> third-parties, and we want our cross-platform SDK to be able to vend the 
> appropriate image resources. So the model object for Brand X could have an 
> ‘icon’ property and the existence of the icon would be verified when we 
> compile the SDK. That SDK could then be used on an iOS device, where the icon 
> is bound to a UIImageView, or on a server, which might render the icon as 
> part of a web-page, or on a cheap linux-based kiosk with a GTK+ UI. That’s my 
> dream.

Just to clarify: I mean that the SDK vends multiple “Brand” objects, each of 
which *must* be displayed with a particular icon. So we can’t just build a 
different SDK for each brand - each build must include resources for all brands.

- Karl


___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-evolution] [Discussion] Resources

[Karl Wagner via swift-corelibs-dev]

> On 25. Sep 2017, at 18:54, Rick Ballard via swift-evolution 
>  wrote:
> 
> Hi Karl and Keith,
> 
> (+ swift-build-dev and swift-corelibs-dev)
> 
> The SwiftPM core team has had some preliminary discussions already with the 
> swift-corelibs team about the best way to support resources; whatever we do 
> here will likely be a collaboration between SwiftPM and Foundation. We're 
> currently defining our roadmap for SwiftPM in Swift 5, and it's not clear yet 
> whether resource support will fit into this year or not, but either way it's 
> clearly something we'll want to do. We're looking to encourage a thriving 
> developer community around the Swift package manager, and we know that this 
> will be important for many uses. If there are other limitations that are 
> currently holding people back, we'd welcome feedback (and contributions!).
> 
> While we're not actively working on a proposal for resource support at the 
> moment, if you have particular thoughts, please feel free to share them, 
> possibly cross-posted between swift-build-dev, swift-corelibs-dev, and 
> swift-evolution.
> 
> Cheers,
> 
>   - Rick
> 

Thanks Rick, that’s very interesting.

I have been bouncing some ideas around my head about how to incorporate 
external resource files as first-class “source” elements of a Swift application 
(similar to the “resource literals” and “image literals” that we have for Xcode 
integration).

Android has the “R” system, which generates resource-ids for things like image 
and layout-xml resources. I don’t know if that’s a common system used by a lot 
of platforms, but I first encountered it with Android and it has some features 
I really like (like compile-time checking that resources exist). I’ve recently 
been using the “R.Swift” library [1] after a colleague's recommendation, which 
generates a similar-style interface for Swift projects, and I think that’s also 
pretty nifty. It improves on the Android system by properly-typing things like 
image and layout resources (Android reduces them all to integer IDs). I could 
imagine something like that either built-in to Swift itself, or as a component 
of SwiftPM.

We would also need some substantial runtime support. Apple’s platforms 
introduce resource variations for different devices, localisations, screen 
densities, colour profiles, etc - and that’s why they have their own “asset 
catalog” format; to manage all of that complexity. A good cross-platform 
resources abstraction would need to match that and include some way for each 
platform to resolve its ideal variation of the resource.

There are times when rich assets belong below the UI layer. For example, I’m 
creating a cross-platform SDK for a large company with multiple subsidiary 
brands. The branding assets are specific in contracts between us and 
third-parties, and we want our cross-platform SDK to be able to vend the 
appropriate image resources. So the model object for Brand X could have an 
‘icon’ property and the existence of the icon would be verified when we compile 
the SDK. That SDK could then be used on an iOS device, where the icon is bound 
to a UIImageView, or on a server, which might render the icon as part of a 
web-page, or on a cheap linux-based kiosk with a GTK+ UI. That’s my dream.

- Karl

[1]: https://github.com/mac-cain13/R.swift

> 
>> On Sep 22, 2017, at 9:41 AM, Keith Smiley via swift-evolution 
>>  wrote:
>> 
>> This is one of the big blockers for our iOS team in moving to SwiftPM. Not 
>> all of our internal libraries have resources, but at the very least our UI 
>> libraries contain xibs and some images, and more commonly our libraries at 
>> least have a Localizable.strings file.
>> 
>> We've started moving over to resource bundles to make working with static 
>> libraries simpler, which also obviously aren't currently supporting with 
>> SwiftPM / cross platform.
>> 
>> I think it would be great if SwiftPM could solve this use case!
>> 
>> --
>> Keith Smiley
>> 
>> On 09/22, Taylor Swift via swift-evolution wrote:
>>> I have never once felt a need to distribute a library with an icon
>>> 
>>> On Fri, Sep 22, 2017 at 10:43 AM, Karl Wagner via swift-evolution <
>>> swift-evolut...@swift.org> wrote:
>>> 
 
> On 21. Sep 2017, at 18:51, Karl Wagner via swift-evolution <
 swift-evolut...@swift.org> wrote:
> 
> Hi everybody!
> 
> I’m really happy that Swift 4 is out, and it’s great that there’s
 already so much active discussion about Swift 5 (concurrency, etc). I find
 I’m running in to language roadblocks less and less, and the improvements
 to the generics system have really improved a lot of my code. It’s really
 enjoyable to program in Swift, so thanks to everybody who made it possible.
> 
> When I think about what’s missing from Swift, I think of modules. We all
 like to write modular code, and aside from the entire discussion about
 submodules, the way that you glue separate modules together in 

Re: [swift-corelibs-dev] Cancelable DispatchQueue.concurrentPerform

[Karl Wagner via swift-corelibs-dev]

On 24 Feb 2017, at 09:48, Brent Royal-Gordon  wrote:

On Feb 23, 2017, at 8:35 AM, Karl Wagner via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

Would it be possible to make a cancelable version of
DispatchQueue.concurrentPerform,
allowing you to abort any yet-to-be-scheduled blocks?

The use-case is for when you’re concurrently performing a job and one of
them sets a flag or fails in a way which already defines the result.
Further execution wouldn’t affect the outcome, so it would be nice if an
operation could flag back to concurrentPerform that it doesn’t have to
schedule any more jobs.

For a real-world example, see this concurrent RandomAccessCollection
wrapper I was building: https://gist.github.com/karwa/
43ae838809cc68d317003f2885c71572


Your example is:


   var _error: Error?
   DispatchQueue.concurrentPerform(iterations: numericCast(count)) {
 do{ try body($0)   }
 catch { _error = error } // TODO: lock. Would be cool if we could
cancel future iterations, too...
   }
   if let error = _error {
 try rescue(error)
   }

So how would cancelability be superior to saying this?

   var _error: Error?
   DispatchQueue.concurrentPerform(iterations: numericCast(count)) {
 guard _error == nil else { return }
 do{ try body($0)   }
 catch { _error = error } // TODO: lock. Would be cool if we could
cancel future iterations, too...
   }
   if let error = _error {
 try rescue(error)
   }

-- 
Brent Royal-Gordon
Architechies


That's a fair point, I could do that in order to skip the body. In general
though, the size of the collection may be very large - we could be queuing
up thousands of no-op blocks after the first element threw an error (or
signalled a value, from a function like "contains"). It would be nice if we
could propagate the fact that the outcome has already been determined up to
Dispatch, which could then simply not bother to queue any more blocks.

I've kind-of worked around it by using a batched concurrentPerform for the
methods where we can maybe expect early termination (such as contains).

- Karl
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Cancelable DispatchQueue.concurrentPerform

[Karl Wagner via swift-corelibs-dev]

Would it be possible to make a cancelable version of 
DispatchQueue.concurrentPerform, allowing you to abort any yet-to-be-scheduled 
blocks?

The use-case is for when you’re concurrently performing a job and one of them 
sets a flag or fails in a way which already defines the result. Further 
execution wouldn’t affect the outcome, so it would be nice if an operation 
could flag back to concurrentPerform that it doesn’t have to schedule any more 
jobs.

For a real-world example, see this concurrent RandomAccessCollection wrapper I 
was building: https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572 


It would be beneficial if we could stop early in the case of errors (see: 
_forEach), or if some global flag is set (see: contains).

- Karl___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev