On Mon, Oct 17, 2016 at 11:57 AM, Jacob Peck wrote:
>
Why is this suddenly an issue?
A better answer is that I have been working on distribution for the last
three days. Problems come up in that context that we completely ignore
normally.
Let's be clear. The new
From: Edward K. Ream <edream...@gmail.com>
To: leo-editor <leo-editor@googlegroups.com>
Sent: Monday, October 17, 2016 1:40 PM
Subject: Re: Fw: Proposal: remove commit_timestamp.json
On Mon, Oct 17, 2016 at 11:57 AM, Jacob Peck <gatesph...@gmail.com> wrote:
On Mon, Oct 17, 2016 at 11:57 AM, Jacob Peck wrote:
> I'm with Terry on this -- the commit_timestamp.json file has been
> immensely helpful in debugging user issues in the past. Relegating the
> commit hash to some funky filename is not an acceptable option.
>
Ok. I can
*Subject:* Re: Proposal: remove commit_timestamp.json
On Monday, October 17, 2016 at 9:04:52 AM UTC-5, Terry Brown
wrote:
I'm not really sure this has any utility :-/
I am about to release Leo 5.4b1. Imo, the new scheme works
very well.
[meant to post to the list, not just Edward]
From: Edward K. Ream <edream...@gmail.com>
To: leo-editor <leo-editor@googlegroups.com>
Cc: terry_n_br...@yahoo.com
Sent: Monday, October 17, 2016 11:23 AM
Subject: Re: Proposal: remove commit_timestamp.json
On Monday, October 1
On Monday, October 17, 2016 at 11:23:08 AM UTC-5, Edward K. Ream wrote:
> To recap, the new scheme is *much *better than the old because:
That summary, while true, doesn't get to the heart of the matter. And it's
repetitious.
In fact, we need commit_timestamp.json only at the *exact instant*
On Monday, October 17, 2016 at 9:04:52 AM UTC-5, Terry Brown wrote:
I'm not really sure this has any utility :-/
>
I am about to release Leo 5.4b1. Imo, the new scheme works very well.
Leo *always* reports first 8 characters of the git hash and git date, even
when there is no git around, which
From: Edward K. Ream <edream...@gmail.com>
To: leo-editor <leo-editor@googlegroups.com>
Sent: Monday, October 17, 2016 3:51 AM
Subject: Re: Proposal: remove commit_timestamp.json
On Sun, Oct 16, 2016 at 8:20 PM, Mike Hodson <myst...@gmail.com> wrote:
On Sun, Oct 1
On Monday, October 17, 2016 at 5:24:23 AM UTC-5, Edward K. Ream wrote:
Rev 4c953099 puts the new scheme in place. It seems to work well.
>
> There is now no need for any git hooks. You can disable them if you like,
> but they won't interfere with anything if they exist.
>
> The format of
On Mon, Oct 17, 2016 at 5:17 AM, Edward K. Ream wrote:
Rev 4c953099 puts the new scheme in place. It seems to work well.
There is now no need for any git hooks. You can disable them if you like,
but they won't interfere with anything if they exist.
The format of
On Mon, Oct 17, 2016 at 3:51 AM, Edward K. Ream wrote:
When I awoke early this morning, I saw the way forward. It should satisfy
> everybody:
>
Rev 4c953099 puts the new scheme in place. It seems to work well.
There is now no need for any git hooks. You can
On Mon, Oct 17, 2016 at 3:51 AM, Edward K. Ream wrote:
>
>
> When I awoke early this morning, I saw the way forward. It should satisfy
> everybody:
>
[snip]
2. Create leo/core/
>
> commit_timestamp.json in @button make-leo in leoDist.leo.
>
The create_json
On Sun, Oct 16, 2016 at 8:20 PM, Mike Hodson wrote:
On Sun, Oct 16, 2016 at 7:12 PM, Edward K. Ream wrote:
> > Here's an example. I downloaded
> > leo-editor-281522323a89c27b7c58338b1eaa624cbd383078.zip
> > from two days ago.
>
> How?
>
From the two
On Sun, 16 Oct 2016 19:20:23 -0600
Mike Hodson wrote:
> That said, I did more digging. Seems that the full hash is contained
> -as a comment- in the zip file...
> With >2000 files in the zip file, infozip at the commandline shows the
> comment -at the top- and in 1 second flat
On Sun, 16 Oct 2016 20:12:26 -0500
"Edward K. Ream" wrote:
> On Sun, Oct 16, 2016 at 7:49 PM, Mike Hodson
> wrote:
>
> > On Sun, Oct 16, 2016 at 4:24 PM, Edward K. Ream
> > wrote:
> > > The zip file's name contains the commit
On Sun, Oct 16, 2016 at 7:12 PM, Edward K. Ream wrote:
> Here's an example. I downloaded
> leo-editor-281522323a89c27b7c58338b1eaa624cbd383078.zip
> from two days ago.
How?
I mean I must be missing something horribly wrong if I'm going to the
same URL posted by Terry and
On Sun, Oct 16, 2016 at 7:49 PM, Mike Hodson wrote:
> On Sun, Oct 16, 2016 at 4:24 PM, Edward K. Ream
> wrote:
> > The zip file's name contains the commit hash, so the user can find out
> the
>
> exact version.
>
> Where exactly am I supposed to be
And, there is no hash in the filename. The filename it downloads is
either "master" "master.zip" or "leo-editor-master.zip" depending on
Chrome, Curl, or Wget naming the file (and/or after following the
redirect manually with curl)
Thanks,
Mike
On Sun, Oct 16, 2016 at 6:49 PM, Mike Hodson
On Sun, Oct 16, 2016 at 4:24 PM, Edward K. Ream wrote:
> The zip file's name contains the commit hash, so the user can find out the
> exact version. Isn't that enough? I don't want write any more code to deal
> with this issue.
>
I just tried downloading the master.zip from
On Sun, Oct 16, 2016 at 5:13 PM, Edward K. Ream wrote:
But I see your point: the daily builds won't have detailed version info.
>
[snip]
> What to do about daily snapshots? Maybe the script that creates the
> snapshot could create commit_timestamp.json.
>
Heh. The zip
On Sunday, October 16, 2016 at 1:15:56 PM UTC-5, Edward K. Ream wrote:
When this code is run outside a git repo, git log will issue a "fatal"
> [sic] error. This will typically be true when the user is running an
> "official" release. We can suppress such irrelevant messages by adding this
>
On Sun, Oct 16, 2016 at 4:08 PM, 'Terry Brown' via leo-editor
So I'd argue for leaving commit_timestamp.json as is and living with
> the two shortcomings you identified. But if it's not bearable, we can
> do something like you suggest.
>
I've already done what I suggested, and it works fine,
On Sun, 16 Oct 2016 09:18:02 -0700 (PDT)
"Edward K. Ream" wrote:
> At present, leoVersion.py gets version info by parsing
> leo/core/commit_timestamp.json. There are at least two unacceptable
> problems with this approach:
>
> 1. The dates don't get updated if a developer
On Sunday, October 16, 2016 at 11:50:00 AM UTC-5, Edward K. Ream wrote:
>
> On Sunday, October 16, 2016 at 11:18:02 AM UTC-5, Edward K. Ream wrote:
>
> p = subprocess.Popen(
>> ["git", "log" , '-1', '--date=default-local'],
>> stdout=subprocess.PIPE,
>> shell=True)
>>
>
When this code
On Sunday, October 16, 2016 at 11:18:02 AM UTC-5, Edward K. Ream wrote:
p = subprocess.Popen(
> ["git", "log" , '-1', '--date=default-local'],
> stdout=subprocess.PIPE,
> shell=True)
>
Testing on Linux shows that the shell argument should be set as follows:
At present, leoVersion.py gets version info by parsing
leo/core/commit_timestamp.json. There are at least two unacceptable
problems with this approach:
1. The dates don't get updated if a developer (like me!) forgets to install
the git hooks.
Just today I noticed that the last update was
26 matches
Mail list logo