Hi, From my past experience, I agree with Robert that I’d be more leaning toward a pre-compiled binary. My understanding is that this makes building, in the right environment, much easier, because now the build process is documented as a Github Action or whatever Robert finally decides to go for. It sounds like it’d also lead to lower barrier to entry for understanding and modifying the code, because of nicer organisation. I hate it when software is just one loooooong file, because usually that means longer time spent figuring out where the bug is actually happening. Historically, I’ve had much more stable experiences when something has been compiled instead of throwing an error at runtime, so that certainly colours my opinion. Thanks for the great work, Parham > On 24 Oct 2023, at 20:06, Robert Melton (via emacspeak Mailing List) <emacspeak@xxxxxxxxxxxxx> wrote: > > Haden-- > > I will play around with it some, but it seems like the complexity of swift builds and how it mostly works > has become more complex. Additionally, I think having a nice trustworthy pre-compiled binary might > be more important to me than entry ease. But I would love to hear from the community. I am very > worried about messaging compile problems up if I use the script approach. > > Not saying no, just, considering how that works with like package.swift and other build things that > modern swift leverages for OS targeting and other features like import order. > >> On Oct 24, 2023, at 13:57, Haden Pike (via emacspeak Mailing List) <emacspeak@xxxxxxxxxxxxx> wrote: >> >> Forgot to reply to the list. >> >> Rather than merging the whole thing, can you just add a file like >> >> #!/usr/bin/env swift >> import server >> >> server.main() >> >> Then the user can set dtk-server to this or the compiled one? >> >> Haden >> >> On 10/24/2023 11:57 AM, Robert Melton wrote: >>> Haden-- >>> >>> I actually had it built that way initially. My reasons for changing it to prebuilt are: >>> >>> 1. Easier multi-file organization >>> 2. Fail at build-time not at run-time. This is a big one for me, as it makes it a good pairing with >>> the python version, which fails at runtime. >>> 3. The compile time can take a bit which would really slow startup and possibly confuse. >>> 4. Not sure how to message missing swift / broken compile from inside emacs. >>> 5. Follows Apples best practices to build it using the Swift project structure >>> >>> That said, I wonder if this is a why-not-both situation. I could merge my structure into one >>> large file with the swift header, then you could be pre-compiled or ad-hoc compiled. >>> >>>> On Oct 24, 2023, at 11:38, Haden Pike (via emacspeak Mailing List) <emacspeak@xxxxxxxxxxxxx> wrote: >>>> >>>> I don't have a Mac any more, but I think Swift could also be used as an interpreter? So you would add >>>> >>>> #!/usr/bin/env xcrun swift >>>> >>>> to the top of the server, and the user just has to have the xcode command line tools installed. Seems easier than building a binary. >>> >> Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx >> To unsubscribe send email to: >> emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe > > -- > Robert "robertmeta" Melton > > Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx > To unsubscribe send email to: > emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe
|Full archive May 1995 - present by Year|Search the archive|
If you have questions about this archive or had problems using it, please contact us.