Emacspeak discussion list

[Parham Doustdar <parham90 AT gmail.com>]

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 AT emacspeak.net> 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 AT emacspeak.net> 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 AT emacspeak.net> 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 AT emacspeak.net
>> To unsubscribe send email to:
>> emacspeak-request AT emacspeak.net with a subject of: unsubscribe
> 
> -- 
> Robert "robertmeta" Melton
> 
> Emacspeak discussion list -- emacspeak AT emacspeak.net
> To unsubscribe send email to:
> emacspeak-request AT emacspeak.net with a subject of: unsubscribe