Sounds like you are already in good shape!
Robby
On Tue, Feb 5, 2019 at 12:57 AM Laurent wrote:
> On Mon, Feb 4, 2019 at 9:55 PM Robby Findler
> wrote:
>
>> > Possibly. I'm not sure what would be the best option yet, I'll think
>> about it but I welcome suggestions.
>>
>> I think the main thin
On Mon, Feb 4, 2019 at 9:55 PM Robby Findler
wrote:
> > Possibly. I'm not sure what would be the best option yet, I'll think
> about it but I welcome suggestions.
>
> I think the main thing should be to avoid any uncaught exceptions (if
> they happen while quickscript starts up, it will get disab
On Mon, Feb 4, 2019 at 8:34 AM Laurent wrote:
> On Sun, Feb 3, 2019 at 7:00 PM Robby Findler
> wrote:
>> On Sun, Feb 3, 2019 at 11:50 AM Laurent wrote:
>>>
>>> I've pushed a repair. It should be integrated with the next racket nightly
>>> release I suppose.
>>>
>>> The fix is to check the comp
On Sun, Feb 3, 2019 at 7:00 PM Robby Findler
wrote:
>
>
> On Sun, Feb 3, 2019 at 11:50 AM Laurent wrote:
>
>> I've pushed a repair. It should be integrated with the next racket
>> nightly release I suppose.
>>
>> The fix is to check the compiled version of all scripts in the library,
>> and if i
On Sun, Feb 3, 2019 at 11:50 AM Laurent wrote:
> I've pushed a repair. It should be integrated with the next racket nightly
> release I suppose.
>
> The fix is to check the compiled version of all scripts in the library,
> and if it differs from the current racket version it gets recompiled. The
I've pushed a repair. It should be integrated with the next racket nightly
release I suppose.
The fix is to check the compiled version of all scripts in the library, and
if it differs from the current racket version it gets recompiled. The bonus
is that scripts that have not been compiled yet will
Okay then, I'll work on a fix tomorrow.
On Fri, Feb 1, 2019 at 1:23 PM Robby Findler
wrote:
> I can't say concretely what will go wrong I am sorry to say. There are
> just a number of moving parts and I can't quite see how they will fail to
> fit together. I am just basing this on my vague, holi
I can't say concretely what will go wrong I am sorry to say. There are just
a number of moving parts and I can't quite see how they will fail to fit
together. I am just basing this on my vague, holistic understanding of how
things work currently. (There are no places where on set of sources is used
On Fri, Feb 1, 2019 at 11:30 AM Robby Findler
wrote:
> My feeling is that our compilation infrastructure isn't really set up to
> work like that currently. In general things will probably be smoother if
> there is only the expectation that a given set of files is used with only
> one version at a
My feeling is that our compilation infrastructure isn't really set up to
work like that currently. In general things will probably be smoother if
there is only the expectation that a given set of files is used with only
one version at a time.
It is possible that someone may use multiple versions o
Thanks for bringing this up.
Indeed the compile option from the quickscript menu should work, but it's
not ideal.
I'm not a big fan of the copy option. (To me that sounds like asking for
trouble, but I may be wrong.)
A nicer solution may be to simply check if the scripts are compiled with
the cu
As long as the user-scripts won't be lost (i.e. the scripts will be copied
over) it sounds OK.
On Thursday, January 31, 2019 at 10:42:08 PM UTC+1, Robby Findler wrote:
>
> Probably it is best if quickscript (either silently or after asking)
> copied scripts from a version-specific directory to a
Probably it is best if quickscript (either silently or after asking)
copied scripts from a version-specific directory to a new
(version-specific) one, much like how the pkg system works.
Robby
On Thu, Jan 31, 2019 at 3:38 PM Greg Trzeciak wrote:
>
> I had quickscript already installed when upgra
13 matches
Mail list logo