I have a copy of NetBSD src (and pkgsrc) that I interact with nearly daily
if there are specifics of this repo that are needed.
On Dec 18, 2014 11:37 AM, "Baruch Burstein" wrote:
> On Thu, Dec 18, 2014 at 7:34 PM, Richard Hipp wrote:
>>
>>
>> Baruch: Can you pull a /tree from your big repo, do
Thus said Stephan Beal on Thu, 18 Dec 2014 21:33:20 +0100:
> personally i don't feel that minification would gain us much because
> we don't have much css/js, but the points about expiry dates and such
> are valid.
Yes, the scope of my question was limited to minification only; I think
the ex
On Dec 18, 2014, at 2:42 PM, Ron W wrote:
> On Thu, Dec 18, 2014 at 4:20 PM, Warren Young wrote:
> With today’s fast CPUs, Ajax lets us bring back the native client, for all
> practical purposes.
>
> My concern about JS (and Java) is that it is too powerful.
Don’t lump JavaScript and Java tog
On Thu, Dec 18, 2014 at 4:20 PM, Warren Young wrote:
>
> With today’s fast CPUs, Ajax lets us bring back the native client, for all
> practical purposes.
My concern about JS (and Java) is that it is too powerful. And web browsers
are not properly "sand boxing" active content like JS.
I have don
On Thu, Dec 18, 2014 at 1:48 PM, Stephan Beal wrote:
>
> On Thu, Dec 18, 2014 at 7:23 PM, Warren Young wrote:
>>
>> The biggest thing I expected to find missing — and was surprised to find
>> that it is not — is gzip compression on the HTTP layer. That alone will
>> help tremendously with multi-
On Dec 18, 2014, at 1:30 PM, Ron W wrote:
> On Thu, Dec 18, 2014 at 2:48 PM, Stephan Beal wrote:
> true enough - it's just been a question of effort. We keep the JS to a
> minimum (even moreso because it's tedious to add ;).
>
> Perhaps it is good that it is tedious to add/edit the JS?
You mi
On Dec 18, 2014, at 1:29 PM, Andy Bradford wrote:
> Thus said Stephan Beal on Thu, 18 Dec 2014 20:48:03 +0100:
>
>> That infrastructure was only recently added. Over time, more of those
>> resources will be moved into the file-based system. The build process
>> bakes those files into the bina
On Thu, Dec 18, 2014 at 9:30 PM, Ron W wrote:
>
> On Thu, Dec 18, 2014 at 2:48 PM, Stephan Beal
> wrote:
>>
>> true enough - it's just been a question of effort. We keep the JS to a
>> minimum (even moreso because it's tedious to add ;).
>>
>
> Perhaps it is good that it is tedious to add/edit th
On Thu, Dec 18, 2014 at 2:48 PM, Stephan Beal wrote:
>
> true enough - it's just been a question of effort. We keep the JS to a
> minimum (even moreso because it's tedious to add ;).
>
Perhaps it is good that it is tedious to add/edit the JS?
___
fossil
On Thu, Dec 18, 2014 at 9:29 PM, Andy Bradford
wrote:
>
> Who is the target audience for such efforts? Minification is definitely
> useful for highly trafficked websites, but is there really a huge
> concern about statistics on web page loads when it comes to Javascript
> and CSS for Fos
Thus said Stephan Beal on Thu, 18 Dec 2014 20:48:03 +0100:
> That infrastructure was only recently added. Over time, more of those
> resources will be moved into the file-based system. The build process
> bakes those files into the binary, but we could have an intermediate
> step for minificat
On Thu, Dec 18, 2014 at 9:08 PM, Warren Young wrote:
>
> There is one other way to solve it, which would let you keep the tree view
> without spamming the client with the entire tree on the first /tree page
> load: Ajax.
>
There's been some experimentation with "alternative UIs" using AJAX and th
On Dec 18, 2014, at 12:48 PM, Stephan Beal wrote:
> i suspect that some of the lower-hanging fruit, like truncating the UUIDs,
> would initially give us bigger wins with less effort.
Yes, I thought that went without saying. I would have mentioned it in my first
email, only I didn’t know if Fo
On Thu, Dec 18, 2014 at 8:38 PM, Warren Young wrote:
>
> On Dec 18, 2014, at 11:48 AM, Stephan Beal wrote:
>
> > It should be compressing, at least based on what i see in cgi.c.
>
> You skimmed that a bit too fast. I was just commenting that I *expected*
> to find that Fossil didn’t gzip its own
On Dec 18, 2014, at 11:48 AM, Stephan Beal wrote:
> It should be compressing, at least based on what i see in cgi.c.
You skimmed that a bit too fast. I was just commenting that I *expected* to
find that Fossil didn’t gzip its own content, but was surprised to find that it
does.
gzipped conte
On Thu, Dec 18, 2014 at 7:34 PM, Richard Hipp wrote:
>
>
> Baruch: Can you pull a /tree from your big repo, do a "Save As..." of the
> page to a file, check its size, then run gzip across it and check its
> compressed size? Also if you can do "grep '__
On Thu, Dec 18, 2014 at 7:23 PM, Warren Young wrote:
>
> The biggest thing I expected to find missing — and was surprised to find
> that it is not — is gzip compression on the HTTP layer. That alone will
> help tremendously with multi-MB pages. I wonder if the person reporting
> that is counting
On Dec 18, 2014, at 10:43 AM, Martin Gagnon wrote:
> For my 5MB that come from firefox Network profiling, it seems to come
> from compressed value.. When I save-as the page, I get a 31.7MB html
> file. If I gzip this html file, I get a 4.0MB file.
You should test with gzip -1, not the default gz
On Dec 18, 2014, at 9:56 AM, Stephan Beal wrote:
> On Thu, Dec 18, 2014 at 5:47 PM, Richard Hipp wrote:
> much time was required to generate the page on the server. I'm interested to
> know how much time was used to generate some of your multi-megabyte /tree
> pages.
>
> i'd be interested to
On Thu, Dec 18, 2014 at 6:34 PM, Richard Hipp wrote:
>
> One way to really save space would be to send only the first 10 or 16
> bytes of the SHA1 hash in the hyperlink for each file, instead of the full
> 40 bytes. The SHA1 hashes do not compress well, so making that change
> would perhaps make
On Thu, Dec 18, 2014 at 4:39 PM, Richard Hipp wrote:
>
>
> Wow. Are you at liberty to share the rest of the "/stat" page with us?
>
I posted the link above. It is the netbsd src repo.
http://netbsd.sonnenberger.org/stat
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
On Thu, Dec 18, 2014 at 12:34:51PM -0500, Richard Hipp wrote:
>
>
> On Thu, Dec 18, 2014 at 11:56 AM, Stephan Beal wrote:
>
> On Thu, Dec 18, 2014 at 5:47 PM, Richard Hipp wrote:
>
> much time was required to generate the page on the server. I'm
> interested to know how m
On Thu, Dec 18, 2014 at 11:47:43AM -0500, Richard Hipp wrote:
> Martin & Baruch:
>
> Thanks for stress-testing Fossil! I don't have any repositories that are
> quite
> that big. In fact, yours appear to be about 100x larger than any that I test
> with. This means that you are much more likely
On Thu, Dec 18, 2014 at 11:56 AM, Stephan Beal
wrote:
>
> On Thu, Dec 18, 2014 at 5:47 PM, Richard Hipp wrote:
>>
>> much time was required to generate the page on the server. I'm
>> interested to know how much time was used to generate some of your
>> multi-megabyte /tree pages.
>>
>
> i'd be i
On Thu, Dec 18, 2014 at 5:47 PM, Richard Hipp wrote:
>
> much time was required to generate the page on the server. I'm interested
> to know how much time was used to generate some of your multi-megabyte
> /tree pages.
>
i'd be interested to know what those megs are - maybe we can consolidate
sy
Martin & Baruch:
Thanks for stress-testing Fossil! I don't have any repositories that are
quite that big. In fact, yours appear to be about 100x larger than any
that I test with. This means that you are much more likely to hit
performance issues, sooner, than I do.
Please do watch for pages th
On Thu, Dec 18, 2014 at 5:23 PM, Stephan Beal wrote:
>
>
>
insofar as i see in cgi.c, it looks like output is always compressed if
> possible (based on response code and whether or not is_gzippable() returns
> true or not).
>
Which doesn't tell you much. The Content-Length header is the comp
On Thu, Dec 18, 2014 at 5:12 PM, Martin Gagnon wrote:
>
> From firefox Network benchmark, my page is 5.5MB. (not sure if that is
> compressed or not)
>
insofar as i see in cgi.c, it looks like output is always compressed if
possible (based on response code and whether or not is_gzippable() return
On Thu, Dec 18, 2014 at 03:23:02PM +0200, Baruch Burstein wrote:
> On Thu, Dec 18, 2014 at 1:46 PM, Baruch Burstein wrote:
>
>
> On Wed, Dec 17, 2014 at 3:31 AM, Richard Hipp wrote:
>
>
> On Tue, Dec 16, 2014 at 8:17 PM, Stephan Beal
> wrote:
>
> On Wed, Dec
On Thu, Dec 18, 2014 at 3:39 PM, Richard Hipp wrote:
>
> Wow. Are you at liberty to share the rest of the "/stat" page with us?
>
FYI: the 'dbstat' CLI command shows the same info (or essentially the same).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"F
On Thu, Dec 18, 2014 at 9:22 AM, Baruch Burstein
wrote:
>
> On Thu, Dec 18, 2014 at 4:00 PM, Richard Hipp wrote:
>>
>>
>> On Thu, Dec 18, 2014 at 8:57 AM, Baruch Burstein
>> wrote:
>>>
>>> On Thu, Dec 18, 2014 at 3:51 PM, Richard Hipp wrote:
How many separate files are in that project
On Thu, Dec 18, 2014 at 4:00 PM, Richard Hipp wrote:
>
>
> On Thu, Dec 18, 2014 at 8:57 AM, Baruch Burstein
> wrote:
>>
>> On Thu, Dec 18, 2014 at 3:51 PM, Richard Hipp wrote:
>>>
>>> How many separate files are in that project?
>>>
>>
>> How do I check?
>>
>>
> The /stat page. Example: https:
On Thu, Dec 18, 2014 at 8:57 AM, Baruch Burstein
wrote:
>
> On Thu, Dec 18, 2014 at 3:51 PM, Richard Hipp wrote:
>>
>> How many separate files are in that project?
>>
>
> How do I check?
>
>
The /stat page. Example: https://www.fossil-scm.org/fossil/stat
--
D. Richard Hipp
d...@sqlite.org
On Thu, Dec 18, 2014 at 3:51 PM, Richard Hipp wrote:
>
> How many separate files are in that project?
>
How do I check?
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.
On Thu, Dec 18, 2014 at 8:23 AM, Baruch Burstein
wrote:
>
>
> On Thu, Dec 18, 2014 at 1:46 PM, Baruch Burstein
> wrote:
>>
>>
>> On Wed, Dec 17, 2014 at 3:31 AM, Richard Hipp wrote:
>>>
>>>
>>> On Tue, Dec 16, 2014 at 8:17 PM, Stephan Beal
>>> wrote:
On Wed, Dec 17, 2014 at 2:16 AM, S
On Thu, Dec 18, 2014 at 1:46 PM, Baruch Burstein
wrote:
>
>
> On Wed, Dec 17, 2014 at 3:31 AM, Richard Hipp wrote:
>>
>>
>> On Tue, Dec 16, 2014 at 8:17 PM, Stephan Beal
>> wrote:
>>>
>>> On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal
>>> wrote:
Actually... i use the flat view more oft
On Wed, Dec 17, 2014 at 3:31 AM, Richard Hipp wrote:
>
>
> On Tue, Dec 16, 2014 at 8:17 PM, Stephan Beal
> wrote:
>>
>> On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal
>> wrote:
>>>
>>> Actually... i use the flat view more often than not. That's probably
>>> just historical momentum (and the way m
On Wed, Dec 17, 2014 at 3:17 AM, Stephan Beal wrote:
>
> On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal
> wrote:
>>
>> Actually... i use the flat view more often than not. That's probably just
>> historical momentum (and the way my old menus are all set up). i wouldn't
>> whine about loss of flat
On Wed, Dec 17, 2014 at 3:05 AM, Richard Hipp wrote:
>
> I think the flat-view functionality should be preserved. (Who knows how
> many links to the flat-view exist on various wiki pages, tickets, and
> check-in comments.) But I don't see a reason to have it using up valuable
> menu-bar space.
>
Hi Richard,
On 16 December 2014 at 17:05, Richard Hipp wrote:
> Given the much improved tree-view functionality
>
> https://www.fossil-scm.org/fossil/tree?ci=trunk&mtime
>
> Is there really any reason to keep the legacy "Flat-View" on the menu bar?
>
> https://www.fossil-scm.org/fossil/tre
On Dec 16, 2014, at 6:05 PM, Richard Hipp wrote:
> But I don't see a reason to have it using up valuable menu-bar space.
Screen real estate is precious. Nuke that sucker.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fos
On Tue, Dec 16, 2014 at 8:17 PM, Stephan Beal wrote:
>
> On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal
> wrote:
>>
>> Actually... i use the flat view more often than not. That's probably just
>> historical momentum (and the way my old menus are all set up). i wouldn't
>> whine about loss of flat
On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal wrote:
>
> Actually... i use the flat view more often than not. That's probably just
> historical momentum (and the way my old menus are all set up). i wouldn't
> whine about loss of flat view, but also won't argue for its removal.
>
flat mode meaning
On Wed, Dec 17, 2014 at 2:05 AM, Richard Hipp wrote:
>
> Given the much improved tree-view functionality
>
> https://www.fossil-scm.org/fossil/tree?ci=trunk&mtime
>
> Is there really any reason to keep the legacy "Flat-View" on the menu bar?
>
> https://www.fossil-scm.org/fossil/tree?ci=tr
44 matches
Mail list logo
