Linux version - Githubissues

TofPlay commented 7 years ago

Great idea 👍 😁 I'm looking forward to the Linux version 😉

RLovelett commented 7 years ago

Right now the biggest roadblock is that SourceKit still is not distributed by default on Linux. Though at least it does compile. You just have to do it yourself.

Technically it's not distributed on macOS either. But you get it with Xcode. So it's a designation without distinction. Mostly it is not considered a public API yet.

They're getting closer though. That's the majority of the the blocking work that needs to be done.

TofPlay commented 7 years ago

Thanks for the feed back. 🙂 I hope it will unlock quickly. If we want to be able to develop real full stack solutions in Swift we need IDEs on Linux with syntax color, completion and full debugger features. What you do with langserver-swift can really be useful for this. 👍 😁 I am quite surprised that Apple does not see the importance of Linux in the development of Swift. Currently on Ubuntu we have to manually install Swift. We do not even have an official ubuntu package for Swift. This slowed Swift's adoption of Linux. Lldb still has problems with Linux so it's hard to bring and test multi-platform frameworks and others tools on Linux. And also I don't understand why Apple is not interested in distributions like Alpine Linux. Through this kind of micro-distribution may be considered to develop solutions that can be installed in the connected objects. One can thus consider full stack solutions in Swift with mobile applications on one side (iOS), the server part (Ubuntu) and connected objects on the other (Alpine Linux). With Swift we have the potential to do that. Still we need to have good tools that allow us to work on Linux. We can not all do it from macOS with Xcode.

BarronKane commented 7 years ago

Is SourceKit the only thing that's apple specific? In other words, if you compile everything yourself will this work "easily enough" in linux? I understand the lack of a guide, but I might give this a go myself (and maybe try automation) as this would make my projects 10x easier to work with.

damuellen commented 7 years ago

Hey guys maybe that helps you Swift 3.1.1 for Ubuntu 16.04 with SourceKit included

RLovelett commented 7 years ago

Sorry for the delayed response. I've been on vacation! 🏖

@BleuGamer yes and no. There is now support for macOS Logging in master. See here for example. Though technically nothing in the system relies on this logging. So it should be sufficient to just comment them out and compile on Linux.

My expectation was that when SourceKit was compiled and distributed upstream for Linux then I would find or build a cross-platform logging mechanism.

johndpope commented 7 years ago

Seems like there's some competition with another vscode swift extension this one more focused on Linux https://github.com/owensd/vscode-swift/commit/0dd601223b7cf070a8f2b40d73fd0d5414d06f32#commitcomment-22425045

@owensd - can't you guys collaborate? At least you could define a protocol and share? The vapor codebase did this and the different parts of codebase can be hot swapped out for http stack.

Peoples time is valuable (yours included) in debugging supporting documenting patching fixing updating(even reading github issues). Consider there is an army of other developers to rally too ready and willing. Too many github projects die or are forked and die of code rot. Consider adding collaborators to help. People get busy with other stuff, unless your roadmap is like Alamo fire to build a business out of project consider there's power in yielding to others code. 1+1 = 3

owensd commented 7 years ago

@johndpope sure, it's always possible. We've done different approaches to solving the problem. This isn't the only one either, there's at least two others that I know of. But integegration costs time here too and isn't free.

In the stack as I use it, the language server is the least interesting part. I have a common LSP implementation in Swift that any can be used to build language server tools for any code client for any langauge. That's swift-lsp.

In any case, there's a possibility, but I think we have different goals for the projects.

owensd commented 7 years ago

@johndpope To be clear, there are two projects at play here: vscode-swift and the language server (LS). @RLovelett's implementation of the LS bakes in the LSP (language server protocol - communication channel between VS Code and the editor). I created https://github.com/owensd/swift-lsp to allow any code server for any language to use it. Ryan would want to take that dependency. Maybe he does, or maybe he doesn't.

If he did, we'd basically be left with files:

main.swift - the CLI tools that acts as the stdio bridge between the LS and VS Code
langsrv.swift - the implementation of the command handling for the LSP

The other difference is the hosting project: vscode-swift. This the JavaScript project that lives within VS Code. The primary difference here is how we distribute the language server binary. I've started the infrastructure to dynamically pull down the releases from GitHub based on version and platform information.

Again, we can unify here, but we'd need to have the same vision of where we want to go with the plug-in and I haven't talk to Ryan about it at all.

RLovelett commented 7 years ago

I'm open to adding collaborators. Basically everyone that has ever submitted a PR I've invited to be a collaborator. To date that has only been a single person, e.g., @aaroncrespo.

As far as combining efforts I am totally game for that. I started this as a bit of a science experiment. I've proven a lot of things to myself and taught myself a lot of things along the way. So from that stand-point I've already achieved all of my goals.

I'm not 100% sure what the path forward would be but I'm interested and available to collaborate to achieve that goal.

felix91gr commented 6 years ago

Hi, sorry for reviving this old thread.

Fwiw, Sourcekit is now (as of Swift 4.0 actually) supported on and distributed for, Linux!

So... if there's anything I could do to help make this project work, ask for it! I can test stuff for you and try to port a dependency if you need it. :)

RLovelett commented 6 years ago

Not a problem, thank you for the interest and offer.

I've got a branch, fedora-linux-swift-4.1, that I've been working on to get it working on Linux. As far as I know that branch compiles agains 4.1 on Linux. It segfaults almost immediately upon running though. I'm having a hard time figuring out why it segfaults.

Unfortunately, I cannot debug it using LLDB. In short, the problem is that every time I start making progress on this code I run into some fundamental roadblock from the Swift environment itself. For me, development is about momentum. Solving one small problem then moving to the next. I cannot seem to gain any momentum with this on Linux because of fundamental tools not working on Linux.

tl;dr I'd love some help. I'd say the first thing we need to do is getting you to where that branch compiles for you.

felix91gr commented 6 years ago

For me, development is about momentum. Solving one small problem then moving to the next.

It is indeed. Frustration is stronger when you lose your momentum. When progress stalls, you feel like you’re only fighting against the project instead of being rewarded for your work on it.

It segfaults almost immediately upon running though. I'm having a hard time figuring out why it segfaults.

I’m gonna take a look! Maybe it’s some forced unwrapping of a value that happens to be Nil under Linux. Maybe we could try running ASAN and TSAN which were introduced to SPM like a week ago, as well.

tl;dr I'd love some help. I'd say the first thing we need to do is getting you to where that branch compiles for you.

Let’s do this! 💪🏻

felix91gr commented 6 years ago

Allright, I'm trying to compile it. This is the output I get:

Missing Linux Main

Fixed by adding LinuxMain.swift to the Tests/ directory.

felix@felix-X550LD ~/D/P/l/repo> swift build
error: missingLinuxMain
felix@felix-X550LD ~/D/P/l/repo> swift --version
Swift version 4.1-dev (LLVM 7598a1fc69, Clang 8be462d5b8, Swift 5cbecbdaa6)
Target: x86_64-unknown-linux-gnu
felix@felix-X550LD ~/D/P/l/repo> ls
Fixtures/  LICENSE  Makefile  Package.resolved  Package.swift  README.md  settings.xcconfig  Sources/  Tests/
felix@felix-X550LD ~/D/P/l/repo> cd Tests/
felix@felix-X550LD ~/D/P/l/r/Tests> touch LinuxMain.swift
felix@felix-X550LD ~/D/P/l/r/Tests> cd ..

Deprecated `flatMap`

Is just a warning, so I wanted it separated from the next point

felix@felix-X550LD ~/D/P/l/repo> swift build
Compile clibc libc.c
Compile Swift Module 'PackageDescription' (6 sources)
Compile Swift Module 'PackageDescription4' (9 sources)
Compile Swift Module 'Runes' (9 sources)
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/PackageDescription/Version+StringLiteralConvertible.swift:52:59: warning: 'flatMap' is deprecated: Please use compactMap(_:) for the case where closure returns an optional value
        let requiredComponents = requiredStringComponents.flatMap({ Int($0) }).filter({ $0 >= 0 })
                                                          ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/PackageDescription/Version+StringLiteralConvertible.swift:52:59: note: use 'compactMap(_:)' instead
        let requiredComponents = requiredStringComponents.flatMap({ Int($0) }).filter({ $0 >= 0 })
                                                          ^~~~~~~
                                                          compactMap
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/PackageDescription4/Version+StringLiteralConvertible.swift:54:14: warning: 'flatMap' is deprecated: Please use compactMap(_:) for the case where closure returns an optional value
            .flatMap({ Int($0) })
             ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/PackageDescription4/Version+StringLiteralConvertible.swift:54:14: note: use 'compactMap(_:)' instead
            .flatMap({ Int($0) })
             ^~~~~~~
             compactMap
Compile Swift Module 'Curry' (1 sources)
Compile Swift Module 'Argo' (19 sources)
Compile Swift Module 'libc' (1 sources)
Compile Swift Module 'POSIX' (11 sources)
Compile Swift Module 'Basic' (34 sources)
Compile Swift Module 'SourceKitter' (10 sources)

Weird errors in Ogra

This is where it falls. Must be some 4.1 quirk -- does the branch compile for you on Mac OS?

Compile Swift Module 'Ogra' (1 sources)
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:95:128: warning: redundant same-type constraint 'Wrapped.Iterator.Element' == 'Wrapped.Element'
extension Optional where Wrapped: Collection & ExpressibleByArrayLiteral, Wrapped.Element: Encodable, Wrapped.Iterator.Element == Wrapped.Element {
                                                                                                                               ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:95:33: note: previous same-type constraint 'Wrapped.Element' == 'Wrapped.Iterator.Element' implied here
extension Optional where Wrapped: Collection & ExpressibleByArrayLiteral, Wrapped.Element: Encodable, Wrapped.Iterator.Element == Wrapped.Element {
                                ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:89:102: warning: redundant conformance constraint 'Self.Element': 'Encodable'
extension Collection where Self: ExpressibleByArrayLiteral, Self.Element: Encodable, Iterator.Element: Encodable {
                                                                                                     ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:89:73: note: conformance constraint 'Self.Element': 'Encodable' written here
extension Collection where Self: ExpressibleByArrayLiteral, Self.Element: Encodable, Iterator.Element: Encodable {
                                                                        ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:36:18: error: cannot convert value of type 'Int' to type 'NSNumber' in coercion
                return .number(self as NSNumber)
                               ^~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:42:18: error: cannot convert value of type 'Double' to type 'NSNumber' in coercion
                return .number(self as NSNumber)
                               ^~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:48:18: error: cannot convert value of type 'Float' to type 'NSNumber' in coercion
                return .number(self as NSNumber)
                               ^~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:54:18: error: cannot convert value of type 'UInt' to type 'NSNumber' in coercion
                return .number(self as NSNumber)
                               ^~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:109:29: error: cannot convert value of type 'Int' to type 'NSNumber' in coercion
        return .number(self.rawValue as NSNumber)
                       ~~~~~^~~~~~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:115:29: error: cannot convert value of type 'Double' to type 'NSNumber' in coercion
        return .number(self.rawValue as NSNumber)
                       ~~~~~^~~~~~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:121:29: error: cannot convert value of type 'Float' to type 'NSNumber' in coercion
        return .number(self.rawValue as NSNumber)
                       ~~~~~^~~~~~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/Ogra.git--6274117797643919272/Sources/Encodable.swift:127:29: error: cannot convert value of type 'UInt' to type 'NSNumber' in coercion
        return .number(self.rawValue as NSNumber)
                       ~~~~~^~~~~~~~
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/Basic/OutputByteStream.swift:121:22: warning: redundant conformance constraint 'C.SubSequence': 'Collection'
        C.SubSequence: Collection {
                     ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/Basic/OutputByteStream.swift:118:32: note: conformance constraint 'C.SubSequence': 'Collection' implied here
    public final func write<C: Collection>(collection bytes: C) where
                               ^
/home/felix/Documents/Programming/langserver-swift/repo/.build/checkouts/swift-package-manager.git-3958815692239172949/Sources/Basic/OutputByteStream.swift:119:11: warning: 'IndexDistance' is deprecated: all index distances are now of type Int
        C.IndexDistance == Int,
          ^
error: terminated(1): /home/felix/Documents/Programming/Binaries/swift/swift-4.1-snapshot/usr/bin/swift-build-tool -f /home/felix/Documents/Programming/langserver-swift/repo/.build/debug.yaml main output:

felix@felix-X550LD ~/D/P/l/repo>

felix91gr commented 6 years ago

Also: if you prefer somewhere else to have this debugging back and forth chat, tell me where to go ;) Otherwise, I'm happy to work on this here, through Github's issues.

RLovelett commented 6 years ago

Also: if you prefer somewhere else to have this debugging back and forth chat, tell me where to go ;) Otherwise, I'm happy to work on this here, through Github's issues.

There is a Gitter room for this project. As you'll see no one has ever used it. But if you want to use it I'd be fine with that. Also, there is a WIP PR for this branch #36.

Weird errors in Ogra

Those Ogra changes should have already been fixed in my fork and incorporated in 5f140bbafc31b7fb25ff5710b844e4fdbd110e97. Do you have those commits?

RLovelett commented 6 years ago

@felix91gr I've included all the Swift 4.1 changes into master. All those warnings and such should be gone now. I've also rebased the fedora-linux-swift-4.1 so that it includes those fixes for the warnings/errors.

felix91gr commented 6 years ago

There is a Gitter room for this project. As you'll see no one has ever used it. But if you want to use it I'd be fine with that.

Ohh, the Gitter would be great :)

Do you have those commits?

Sort of. I have these commits.

felix91gr commented 6 years ago

It builds!

felix@felix-X550LD ~/D/P/l/repo> git pull origin fedora-linux-swift-4.1 
From https://github.com/RLovelett/langserver-swift
 * branch            fedora-linux-swift-4.1 -> FETCH_HEAD
Already up-to-date.
felix@felix-X550LD ~/D/P/l/repo> git status
On branch origin/fedora-linux-swift-4.1
nothing to commit, working directory clean
felix@felix-X550LD ~/D/P/l/repo> ls
Fixtures/  LICENSE  Makefile  Package.resolved  Package.swift  README.md  settings.xcconfig  Sources/  Tests/
felix@felix-X550LD ~/D/P/l/repo> rm -rf .build/
felix@felix-X550LD ~/D/P/l/repo> swift build
Fetching https://github.com/thoughtbot/Curry.git
Fetching https://github.com/RLovelett/Ogra.git
Fetching https://github.com/RLovelett/SourceKit.git
Fetching https://github.com/thoughtbot/Runes.git
Fetching https://github.com/RLovelett/swift-package-manager.git
Fetching https://github.com/thoughtbot/Argo.git
Cloning https://github.com/thoughtbot/Curry.git
Resolving https://github.com/thoughtbot/Curry.git at 3.0.0
Cloning https://github.com/RLovelett/swift-package-manager.git
Resolving https://github.com/RLovelett/swift-package-manager.git at swift-4.1-branch
Cloning https://github.com/RLovelett/Ogra.git
Resolving https://github.com/RLovelett/Ogra.git at master
Cloning https://github.com/thoughtbot/Runes.git
Resolving https://github.com/thoughtbot/Runes.git at 4.1.0
Cloning https://github.com/RLovelett/SourceKit.git
Resolving https://github.com/RLovelett/SourceKit.git at 1.0.2
Cloning https://github.com/thoughtbot/Argo.git
Resolving https://github.com/thoughtbot/Argo.git at 4.1.2
Compile clibc libc.c
Compile Swift Module 'PackageDescription' (6 sources)
Compile Swift Module 'PackageDescription4' (9 sources)
Compile Swift Module 'Runes' (9 sources)
Compile Swift Module 'Curry' (1 sources)
Compile Swift Module 'libc' (1 sources)
Compile Swift Module 'Argo' (19 sources)
Compile Swift Module 'POSIX' (11 sources)
Compile Swift Module 'Basic' (36 sources)
Compile Swift Module 'SourceKitter' (11 sources)
Compile Swift Module 'Ogra' (1 sources)
Compile Swift Module 'Utility' (19 sources)
Compile Swift Module 'SourceControl' (4 sources)
Compile Swift Module 'PackageModel' (7 sources)
Compile Swift Module 'PackageLoading' (9 sources)
Compile Swift Module 'BaseProtocol' (9 sources)
Compile Swift Module 'PackageGraph' (6 sources)
Compile Swift Module 'Xcodeproj' (7 sources)
Compile Swift Module 'Build' (7 sources)
Compile Swift Module 'Workspace' (7 sources)
Compile Swift Module 'Commands' (13 sources)
Linking ./.build/x86_64-unknown-linux/debug/libSwiftPM.so
Compile Swift Module 'LanguageServerProtocol' (37 sources)
Compile Swift Module 'LanguageServer' (2 sources)
Linking ./.build/x86_64-unknown-linux/debug/langserver-swift

felix91gr commented 6 years ago

Allright. I'll start filling the LinuxMain.swift file to see what happens.

felix91gr commented 6 years ago

Okay, I've extended test coverage to Linux. I'll make a pull request.

Edit: PR is live on #39 :)

samdeane commented 6 years ago

I'm definitely interested in the Linux progress too. I've been hacking around with some Atom/swift integration, and recently got pointed in the direction of the new Atom IDE stuff. It looks like that'll require an LSP implementation for Swift.

The question I have therefore, really touches on what @owensd was talking about in an earlier comment. To what extent (if any) is this project tied to VS Code at the moment?

RLovelett commented 6 years ago

To what extent (if any) is this project tied to VS Code at the moment?

tl;dr None.

So I feel weird saying none because the LSP is developed by Microsoft for VSCode. VSCode is the reference implementation of the LSP. When in doubt whatever VSCode does is what the LSP is supposed to do. This was especially evident a few years ago because they would actively change the protocol to document/match what VSCode does/did.

Sure, at this point its got a lot of other implementations and they are trying to build a community around the protocol. So they don't just change it on a whim any more. But still...

My point is I've done nothing to lock this to VSCode. If it is found to be locked to that then I'll do what I can to help separate it from that.

Linux Support Status

At this point, 90% of what prevents this from working on Linux is inconsistency in the implementation of swift-corelibs-foundation and swift-corelibs-libdispatch. For instance, this and this and this and this. So realistically, the earliest that this could be supported on Swift would be 4.2 assuming upstream patches landed in Swift. My bet though is even once those land, we'll find others and it'll be Swift 5 (or a unofficially patched version of Swift 4.2) that'll actually allow all this to work.

Most frustratingly there are an unknown number of issues in this implementation still yet to be found because of being stuck on many of these foundational issues.

I don't want to be too much of a naysayer about the whole thing but I think if you look at the server working group, or this, or this, it about sums up the state of Swift on Linux. Stagnant to the point of possibly being a zombie. Some progress is being made but it might be too little too late as the initial launch momentum is quickly running out.

It's a chicken and an egg situation. The tools (tooling?) to work on Swift on Linux do not exist. What does exist is buggy and/or half implemented. Developing the core libraries is slow and hard. In my opinion, the Swift build-script is arcane bordering on impossible to scale. Therefore there are no developers. Because there are no Swift on Linux developers there is no big push for tooling. Or at least, this is my perspective on the whole thing.

Bottom Line

I am still working on this project. It is still maintained. Despite me not responding to some of the issues on here.

Personally I am no longer actively patching bugs on the macOS implementation, or not until I've fixed the Linux implementation (pull requests are always welcome). I have proven to myself the concept will work. My priority is Linux. Xcode works on macOS. This tool is needed on Linux.

Help is always appreciated.

samdeane commented 6 years ago

Thanks for the update - and just to be clear, it was an innocent question and no criticism was implied :)

It's possible that I'll be in a position to help. Right now I'm just trying to figure out the alternatives, and from them, my priorities.

RLovelett commented 6 years ago

and just to be clear, it was an innocent question and no criticism was implied

No worries, I new it was an innocent question and I did not feel indicted by you.

Though, if it seems I am frustrated, well you'd be right. Though not at you (or anyone else for that matter). 😄

I kind of used that comment as a cathartic channel to express my feelings on the state of this project and Swift in general. In hind sight, that was unfair to you. I certainly did not mean for this to be off-putting and I hope it was not.

I wanted to provide some sort of status update to anyone who might stumble across this project and wonder/worry why things are in the state they are.

It's possible that I'll be in a position to help. Right now I'm just trying to figure out the alternatives, and from them, my priorities.

Whatever you decide/determine I hope you find what you are looking for. 👍

samdeane commented 6 years ago

Yeah, I figured it was catharsis as much as anything :)

The status update makes a lot of sense too, and is helpful. I hear you on the frustration front :grinning:

FWIW, on Ubuntu 18.04 I get:

17:18 sam@clear-air-turbulence  (fedora-linux-swift-4.1)
langserver-swift > swift --version
Swift version 4.2-dev (LLVM ab46ecfd93, Clang ed8876508e, Swift 867ffdd16c)
Target: x86_64-unknown-linux-gnu

17:20 sam@clear-air-turbulence  (fedora-linux-swift-4.1)
langserver-swift > swift test
Test Suite 'All tests' started at 2018-05-22 16:20:52.645
<...>
Test Suite 'All tests' failed at 2018-05-22 16:13:04.771
     Executed 32 tests, with 10 failures (0 unexpected) in 0.021 (0.021) seconds

I can paste in the failures if that helps, but really I'm just giving you another data point and confirming what you probably already know.

samdeane commented 6 years ago

Whatever you decide/determine I hope you find what you are looking for.

Thanks! There's an idea for a song in there somewhere...

Where I'm at is basically:

more familiar with Atom than VS Code
tried some existing Atom auto-completion packages, discovered that they didn't really work on Linux
stupidly said "how hard can it be?"
looked at the LSP ones and decided that it was too much cognitive load for a quick & dirty job
built one which uses source kitten instead; it seems to basically work, but I'm sure could be improved
moved on to the question of debugging, and tried an existing Atom swift debugging package
discovered that it was a few years out of date and really only a sketch anyway
discovered Nuclide, tried that, and didn't like the UI which all felt a bit heavy (generic ide == lots of stuff I don't need right now / don't understand the context of)
stupidly said "how hard can it be?", forked it, and started hacking the sketchy one
via a discussion on the Swift forums, discovered the (relatively) recent existence of the Atom IDE support
looked into that a bit, discovered that the language integration is via LSP (which makes perfect sense)
started revisiting that, hence looking here and at @owensd's project again
looked into the debugger integration of atom-ide-ui, and realised that it's all a repackaged version of Nuclide anyway
decided it was time for a sit down, a rethink, and a nice :tea:

:grin:

samdeane commented 6 years ago

On one hand, wheel-reinvention is a bit dumb, and if Atom-IDE is now a thing, why would I want to waste time hacking together my own UI for setting breakpoints, inspecting variables, etc, etc?

On the other hand, I'm sort of doing this just for fun, and it is also a diversion from what I really want to be doing (writing actual Swift). Just being able to start simple and iterate slowly is therefore quite attractive. The doing-it-in-Atom, build-it-myself route lets me do that. I can tailor it to suit my needs, and I don't have to immediately divert my attention into understanding the protocols associated with VS Code, LSP, Nuclide/Atom-IDE, etc.

The sensible engineer in my says that I should use Atom-IDE for the debugging stuff. Which means there's more incentive for me to actually help get this project working so that Atom-IDE can also provide all the language support, and we end up with a nice unified whole.

The hacker in me is tempted to just keep noodling away with what I have.

Anyhoo - this was all just background to my personal motivation, and is way off topic so I'll shut up now.

felix91gr commented 6 years ago

If you need a DE for Linux, even if it's not Atom-based, you can check out SDE.

But what Ryan is saying is true: we need more cross-platform compatibility for Swift. IMO the most important bridge there is corelibs-foundation. After that is complete, this project and many others could be ported much more easily.

Also, FWIW @RLovelett: Valentin Knabel and I have been working on an index of cross-platform Swift projects. There are many that work 100% on Linux (not all, but most), and most maintainers I've talked to are really nice and really care about cross platform support. So I think there's still hope.

... I'm still hella jealous of the Rust community. Have you seen Cargo? Jesus Christ. They're blooming.

samdeane commented 6 years ago

Thanks @felix91gr. I did try SDE at some point on my journey, but at the time I couldn't get all the things to work. Possibly because I had some other things installed which shouldn't have been, or because I failed to install all the dependencies.

Decentralisation is all very well, but I think part of the problem with the language support model of both VSC and Atom is that there's no clean way to install an authoritative package or set of packages that are known to work together!

As a user, people just want to be able to "turn on Swift support". They shouldn't need to know to use atom-swift89 rather than atom-swift3, or the @vknabel version of SDE not the @jinmingjian one :).

(not that any of this is anyone here's fault - I'm just venting)

samdeane commented 6 years ago

The index looks cool.

If I was being particularly dogmatic, I'd be tempted to say though that your entry requirements should be: Linux support is stable ~or at least planned~

(in other words, Linux support being planned is easy to say... but not much help to anyone using the index)

felix91gr commented 6 years ago

The index looks cool.

If I was being particularly dogmatic, I'd be tempted to say though that your entry requirements should be: Linux support is stable or at least planned

(in other words, Linux support being planned is easy to say... but not much help to anyone using the index)

Thank you! And yes, I'd tend to agree. But given the state of transition we're in, I'd rather direct people to projects that want to support them. After Foundation is completely implemented for Linux, we can (and maybe should) have a harder stance :)

vknabel commented 6 years ago

As I have been mentioned (thanks btw), I wanted to join this discussion. I didn't know this repo is still maintained.

I agree that the community as a whole needs more cross platform support, which also includes IDE support. I also think Swift IDEs for Linux should be more stable than the underlaying tooling Apple provides: this is where all open source projects I know of currently fail at. New users who explore Swift should not be forced to perform installation steps, we do not know by heart on every platform (luckily they don't need to recompile Swift anymore).

To add something new:

We need a LSP written in Swift on Linux: this project is probably the best approach. The LSP in SDE is tightly coupled to vscode and is written in typescript (two reasons why most Swift users cannot easily contribute). SDE mostly does what it should, but as it started as prototype some parts are quite hacky. I am not sure how the vscode extensions for both projects differ regarding feature set and performance nowadays, but this kind of comparision is irrelevant.
We need a Swift in one-click extension for vscode: Currently there are quite many extensions with a different feature set and which need to be installed differently. While this project is relatively easy to install, sourcekite is not (especially on Linux). Ideally native dependencies should be installed automatically. All of this needs to be coordinated. I started a small board for this some time ago, but did not have enough time to get started.

RLovelett commented 6 years ago

Ideally native dependencies should be installed automatically.

So if you install the C/C++ for Visual Studio Code it does download a number of extra "things" and ensure that they are all configured the first time you launch the plugin.

This inspired me and I have looked into/thought about this a bit. I maintain this as a statically linkable binary. My hope is that in the future, when Swift is ABI stable, there could be a compile step on a CI that makes it for some matrix of supported platforms (e.g., Linux x86_64, macOS x86_64, etc.) and then when the plugin is installed it would just go and download the LSP and install it accordingly. Or maybe for Linux it would be a standard package and it would be a apt get or dnf install away.

Though it should be noted that this is a function of the plugin not the LSP. Or in my case that install step would be a function of vscode-swift and not this.

samdeane commented 6 years ago

Just FYI:

Out of sheer bloody-minded optimism (and the desire to hack), I've created atom-ide-swift.

Right now I'm focussing on the debugger integration, but if we get to the point where langserver-swift is up & running on Linux, I can integrate it in.

samdeane commented 6 years ago

My hope is that in the future, when Swift is ABI stable, there could be a compile step on a CI that makes it for some matrix of supported platforms (e.g., Linux x86_64, macOS x86_64, etc.) and then when the plugin is installed it would just go and download the LSP and install it accordingly

For the atom-autocomplete-swift-sourcekitten package, I currently ask people to enter a path in the preferences to point to the sourcekitten binary.

What I've been considering doing instead is having the package check on first launch, and if necessary cloning the sourcekitten repo locally, then just building sourcekitten with swift build.

Since the package pretty much relies on swift being installed anyway, this feels like a viable option, provided that there are no external dependencies (eg needing apt installation).

xylobol commented 6 years ago

Anything new on this? My team is investigating moving from JS to Swift on the backend, and lack of a language server for our VS Code developers is a bit of a blocker on this.

Thank you in advanced Xylobol

shoorlyne commented 6 years ago

Any progress? Definitely looking forward to any update!

RLovelett commented 6 years ago

Basically this is on indefinite hold until I can get a debugger working on Linux. Which as far as I can tell is a long ways off.

The latest blocker is SR-7932.

RLovelett / langserver-swift

Linux version #18

Missing Linux Main

Deprecated `flatMap`

Weird errors in Ogra

Linux Support Status

Bottom Line

RLovelett / langserver-swift

Linux version #18

Missing Linux Main

Deprecated flatMap

Weird errors in Ogra

Linux Support Status

Bottom Line

Deprecated `flatMap`