Re: [swift-corelibs-dev] Better integration with UNIX tools

2017-11-21 Thread William Dillon via swift-corelibs-dev 
I cosign all of this.  Nice work, Brent.

> On Nov 17, 2017, at 4:47 PM, Brent Royal-Gordon via swift-corelibs-dev 
>  wrote:
> 
>> On Nov 17, 2017, at 11:34 AM, Tony Parker via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> It does seem like there is a possibility of some better convenience API here.
>> 
>> Any ideas on what form it would take? A class method on Process that returns 
>> the output, maybe?
> 
> `Process.run(_:arguments:terminationHandler:)` is not a bad basis for this, 
> other than the first argument being a URL. I might add a variant which does a 
> $PATH search and expands tildes:
> 
>   extension Process {
>   class func runInPath(_ commandName: String, with arguments: 
> [String], terminationHandler: ((Process) -> Void)? = nil) -> Process
>   }
> 
> (I would *not* add a variant which simply shells out, or at least I wouldn't 
> make it the only option. Every scripting language I can think of has this 
> feature, and every one of them discourages its use and pushes people towards 
> something else with pre-split arguments and no shell attack surface.)
> 
> And then add a method which gathers all stdout output and returns it, along 
> with the termination status (throwing if it's a signal):
> 
>   extension Process {
>   func outputAfterExit() throws -> (output: String, status: Int32)
>   }
> 
> The result is not *as* convenient as PHP, but it's a lot safe than running 
> things through a shell, too.
> 
>   let (output, _) = try Task.runInPath("find", with: ["~/Desktop", 
> "-name", "*.png"]).outputAfterExit()
> 
> The biggest problem I see with this design is that expanding tildes in the 
> arguments, but *not* globbing them, happens to be right for this case, but 
> may not be in the general case. One interesting possibility would be to go 
> the custom operator route:
> 
>   /// Returns an absolute path placing `relativePath` in the user's home 
> directory.
>   prefix func ~ (relativePath: String) -> String {
>   return 
> FileManager.default.homeDirectoryForCurrentUser.appendingPathComponent(relativePath).path
>   }
> 
>   let (output, _) = try Task.runInPath("find", with: [~"Desktop", 
> "-name", "*.png"]).outputAfterExit()
> 
> But I'm not sure we'd want that available in million-line Mac apps.
> 
> On the other hand, maybe Foundation's APIs in general are too verbose for 
> scripting. I could imagine a "Foundation.Script" module which added some 
> unprincipled but convenient shortcuts:
> 
>   extension URL: ExpressibleByStringLiteral { // Should be 
> interpolatable too, but we need to redesign that.
>   public init(stringLiteral value: String) {
>   self.init(fileURLWithPath: value)
>   }
>   }
>   public var FS { return FileManager.default }
>   public var ENV { return ProcessInfo.processInfo.environment }
> 
> That might be a good place for a leading tilde operator, too.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Better integration with UNIX tools

2017-11-17 Thread William Dillon via swift-corelibs-dev 
I, to, have wished for such an API.

I think that would be a very welcome addition.

> On Nov 17, 2017, at 11:34 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi Abhi,
> 
> It does seem like there is a possibility of some better convenience API here.
> 
> Any ideas on what form it would take? A class method on Process that returns 
> the output, maybe?
> 
> - Tony
> 
>> On Nov 16, 2017, at 3:34 PM, Abhi Beckert via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Swift is a great shell scripting language except for it's lack of any API to 
>> execute UNIX commands. Compare these two shell scripts:
>> 
>>> #!/usr/bin/php
>>> >> 
>>> $files = `find ~/Desktop -name *.png`;
>>> 
>>> foreach (explode("\n", $files) as $file) {
>>>   // do something with $file
>>> }
>> 
>> -
>> 
>>> #!/usr/bin/swift
>>> 
>>> import Foundation
>>> 
>>> let process = Process()
>>> process.launchPath = "/usr/bin/find"
>>> process.arguments = [
>>>   NSString(string:"~/Desktop").expandingTildeInPath,
>>>   "-name",
>>>   "*.png"
>>> ]
>>> 
>>> let output = Pipe()
>>> process.standardOutput = output
>>> 
>>> process.launch()
>>> 
>>> let files: String
>>> if let filesUtf8 = NSString(data: 
>>> output.fileHandleForReading.readDataToEndOfFile(), encoding: 
>>> String.Encoding.utf8.rawValue) {
>>>   files = filesUtf8 as String
>>> } else {
>>>   files = NSString(data: output.fileHandleForReading.readDataToEndOfFile(), 
>>> encoding: String.Encoding.isoLatin1.rawValue) as NSString! as String
>>> }
>>> 
>>> files.enumerateLines { file, _ in
>>>   // do something with file
>>> }
>> 
>> It's a contrived example, I could have used NSFileManager, but I run into 
>> this all the time integrating with more complex tools such as rsync.
>> 
>> Adding my own high level wrapper around the Process command isn't an option 
>> since there is no good way to import code from another file when executing 
>> swift asa shell script. All your code needs to be in one file.
>> 
>> - Abhi
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Add support for gathering test coverage data on XCTest

2016-12-15 Thread William Dillon via swift-corelibs-dev 
 
I would love for there to be access to test coverage data (especially on 
linux). One thing that concerns me about the way tests work on linux is that 
it’s very easy to miss tests in the allTests method. I’ve always got a nagging 
worry that there are missing tests I don’t know about floating around that 
aren’t running on Linux. This is to say nothing about coverage differences due 
to conditional compilation arising from "#if os(OSX) || os(iOS) || os(watchOS) 
|| os(tvOS)” constructs.

- Will


On December 14, 2016 at 1:16:56 PM, Jacopo Andrea Giola via swift-corelibs-dev 
(swift-corelibs-dev@swift.org(mailto:swift-corelibs-dev@swift.org)) wrote:

> Hi all,  
>  
> I was wondering if it can be a great idea to build the capability of 
> gathering test coverage data inside the XCTest framework to be able to use it 
> for gathering the data on the various platform without having to relay on the 
> Xcode capability.  
>  
> Today the only way a swift project can be gather coverage data during its ci 
> build is to relay on building at least for the macOS platform, and only in 
> that case, generate the xcproj file, running the tests with xcbuild, and 
> after that we can have data to look at.  
>  
> I’m trying to find on GitHub some swift project that has integrated a ci 
> flow, and all the one that at the end wants to have the tests coverage data 
> use this flow, on linux they use the swift cli commands for building and 
> testing the project, and on macOS they use Xcode to gathering the data. 
> Having two different flow for me is kinda crazy, and more crazy is to relay 
> on the fact that if the tests coverage on macOS is 100% it will be even on 
> Linux (or any other platform that Swift will support in the future) counting 
> that in the code there can be different path used based on the platform.  
>  
> Asking on the SwiftPM Slack channel, they point me on this list and here I 
> am, it can be done? There is interest in this from the community?  
> The top will be that the swift test command will automatically generate the 
> coverage data, and we can then pass it some kind of flag for choosing between 
> two or three different output (like JSON, XML or what is the main file format 
> this day to integrate nicely with things around the web and using services 
> like codecov.io(http://codecov.io)).
>  
> - Jacopo ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Duplicate definition of va_list on Arm

2016-08-19 Thread William Dillon via swift-corelibs-dev 
Ok then.  At this point I suppose I'm looking at maintaining a fork of 
libdispatch.  I can't think of any other solutions that make sense.

> On Aug 19, 2016, at 10:31 PM, Pierre Habouzit  wrote:
> 
> Dispatch/dispatch.h is a public header. So not really. 
> 
> -Pierre on his iPhone
> 
> On Aug 19, 2016, at 8:41 PM, William Dillon  <mailto:will...@housedillon.com>> wrote:
> 
>> True enough.  In that case, would be acceptable to match by architecture and 
>> skip the import on arm?
>> 
>>> On Aug 19, 2016, at 5:56 PM, Pierre Habouzit >> <mailto:pie...@habouzit.net>> wrote:
>>> 
>>> the include was added to dispatch specifically to allow dispatch_io to 
>>> build on intel so your patch I think would break Intel.
>>> 
>>> I think the general problem is likely that glibc is not module friendly 
>>> today.
>>> 
>>> -Pierre
>>> 
>>>> On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev 
>>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> In corelibs-foundation project we've been using a patch based on 
>>>> https://github.com/apple/swift-corelibs-foundation/pull/399/files 
>>>> <https://github.com/apple/swift-corelibs-foundation/pull/399/files> for 
>>>> quite some time (summary: remove #include ).  The PR hasn't 
>>>> gotten any where for various reasons.  Currently, I've gotten libdispatch 
>>>> working on arm, but it requires a fix that's essentially identical.  It is 
>>>> part of a PR available here: 
>>>> https://github.com/apple/swift-corelibs-libdispatch/pull/155 
>>>> <https://github.com/apple/swift-corelibs-libdispatch/pull/155>
>>>> 
>>>> I'd like to get this moving forward in both cases, and I'd like to bring 
>>>> it to the list.  What exactly is stdio.h bringing in?  I realize the 
>>>> comment identifies __off_t, but at least on arm that's being provided 
>>>> elsewhere.  Furthermore, __off_t is defined in several places.
>>>> 
>>>> Are there any suggestions for what a satisfactory solution would be to 
>>>> address the duplicate definition of va_list on arm that does not 
>>>> negatively impact other platforms?
>>>> 
>>>> Thanks,
>>>> - Will
>>>> ___
>>>> swift-corelibs-dev mailing list
>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>> 
>> 

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

Re: [swift-corelibs-dev] Duplicate definition of va_list on Arm

2016-08-19 Thread William Dillon via swift-corelibs-dev 
True enough.  In that case, would be acceptable to match by architecture and 
skip the import on arm?

> On Aug 19, 2016, at 5:56 PM, Pierre Habouzit  wrote:
> 
> the include was added to dispatch specifically to allow dispatch_io to build 
> on intel so your patch I think would break Intel.
> 
> I think the general problem is likely that glibc is not module friendly today.
> 
> -Pierre
> 
>> On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> In corelibs-foundation project we've been using a patch based on 
>> https://github.com/apple/swift-corelibs-foundation/pull/399/files 
>> <https://github.com/apple/swift-corelibs-foundation/pull/399/files> for 
>> quite some time (summary: remove #include ).  The PR hasn't gotten 
>> any where for various reasons.  Currently, I've gotten libdispatch working 
>> on arm, but it requires a fix that's essentially identical.  It is part of a 
>> PR available here: 
>> https://github.com/apple/swift-corelibs-libdispatch/pull/155 
>> <https://github.com/apple/swift-corelibs-libdispatch/pull/155>
>> 
>> I'd like to get this moving forward in both cases, and I'd like to bring it 
>> to the list.  What exactly is stdio.h bringing in?  I realize the comment 
>> identifies __off_t, but at least on arm that's being provided elsewhere.  
>> Furthermore, __off_t is defined in several places.
>> 
>> Are there any suggestions for what a satisfactory solution would be to 
>> address the duplicate definition of va_list on arm that does not negatively 
>> impact other platforms?
>> 
>> Thanks,
>> - Will
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

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

[swift-corelibs-dev] Duplicate definition of va_list on Arm

2016-08-19 Thread William Dillon via swift-corelibs-dev 
Hi all,

In corelibs-foundation project we've been using a patch based on 
https://github.com/apple/swift-corelibs-foundation/pull/399/files 
 for quite 
some time (summary: remove #include ).  The PR hasn't gotten any where 
for various reasons.  Currently, I've gotten libdispatch working on arm, but it 
requires a fix that's essentially identical.  It is part of a PR available 
here: https://github.com/apple/swift-corelibs-libdispatch/pull/155

I'd like to get this moving forward in both cases, and I'd like to bring it to 
the list.  What exactly is stdio.h bringing in?  I realize the comment 
identifies __off_t, but at least on arm that's being provided elsewhere.  
Furthermore, __off_t is defined in several places.

Are there any suggestions for what a satisfactory solution would be to address 
the duplicate definition of va_list on arm that does not negatively impact 
other platforms?

Thanks,
- Will___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev