On 2016-05-23 12:38, qznc wrote:

> Mixing fonts is hard. Both fonts must have the same size, but also the
> same x-height [0], which is the height of lowercase letters like x. This
> can be seen very clearly with inline code like "contain a
> <code>dub.json</code>" at the page you linked to. Zoom in (Ctrl+) and
> you see the height difference between "a" and "u".
>
> On websites where fonts are picked from whatever is available on the
> system, this is nearly impossible to get right. You either live with it
> or embed your own fonts via CSS, which bloats the page.
>
> [0] https://en.wikipedia.org/wiki/X-height

A start is to use the same font size ;)

-- 
/Jacob Carlborg

On 2016-05-23 17:40, Sönke Ludwig wrote:

> Oh, okay, misunderstood that. The basic protocol is very simple:
>
> GET /packages/index.json
> Yields a JSON array with all package names
>
> GET /packages/[package].json
> Returns a JSON object with general information about a package,
> including all available versions
>
> GET /packages/[package]/[version].json
> Returns a JSON object with the package recipe of a particular version
> (dub.json format), augmented with some additional fields
>
> GET /packages/[package]/[version].zip
> Yields a zipped up version of the package

So dependencies are fetched when they are discovered based on a package? Wouldn't it be more efficient to have an API call that given a list of packages, returns the full set of dependencies in one call. Then it would be possible to fetch the dependencies in parallel.

-- 
/Jacob Carlborg

Am 24.05.2016 um 08:24 schrieb Jacob Carlborg:
> On 2016-05-23 17:40, Sönke Ludwig wrote:
>
>> Oh, okay, misunderstood that. The basic protocol is very simple:
>>
>> GET /packages/index.json
>> Yields a JSON array with all package names
>>
>> GET /packages/[package].json
>> Returns a JSON object with general information about a package,
>> including all available versions
>>
>> GET /packages/[package]/[version].json
>> Returns a JSON object with the package recipe of a particular version
>> (dub.json format), augmented with some additional fields
>>
>> GET /packages/[package]/[version].zip
>> Yields a zipped up version of the package
>
> So dependencies are fetched when they are discovered based on a package?
> Wouldn't it be more efficient to have an API call that given a list of
> packages, returns the full set of dependencies in one call. Then it
> would be possible to fetch the dependencies in parallel.
>

Since fetching dependencies usually saturates the network connection, that wouldn't save much time (or do you just mean fetching the package recipes in parallel?). But because it also requires full dependency resolution, it would have a considerable impact on server load. And of course that would make it impossible to use a simple file server as a package registry.

On 2016-05-24 08:42, Sönke Ludwig wrote:

> Since fetching dependencies usually saturates the network connection,
> that wouldn't save much time (or do you just mean fetching the package
> recipes in parallel?).

No, I mean fetching the full package in parallel.

> But because it also requires full dependency
> resolution, it would have a considerable impact on server load.

Does it really take that much resources?

> And of course that would make it impossible to use a simple file server as a
> package registry.

How important is that? The client could first try the API call to give the full set of dependencies, if that fail, fallback to the current approach.

-- 
/Jacob Carlborg

On Monday, 23 May 2016 at 09:30:25 UTC, Chris wrote:
> On Monday, 23 May 2016 at 09:23:45 UTC, Sönke Ludwig wrote:
>> Am 23.05.2016 um 11:22 schrieb Chris:
>>> The flavicon is still the old one and appears in search engine results.
>>
>> For some reason, favicons are cached aggressively. It has been updated, but it's hard to get the browsers pick it up.
>
> I thought it might be a caching issue. I don't know about the search engines though. Can you inform them of the update? I opened the page in a different browser and it shows the new favicon, but in the search results it's still the old icon.

My search engine now shows the new favicon.

On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:
> (...)

The new site is cool, except a few annoyances:

1. The font is much thinner than on dlang.org main site (font-weight set to 300 for no good reason), and thus much harder to read. Using #333 for text color instead of pure black makes it even harder. Come on, perhaps most of us already have some sort of vision defects, please do not make it worse.

2. Project READMEs now render with different font which looks weird. (OTOH, the README alone looks nicer and easier on eyes, because plain Helvetica or Arial are just better suited for on-screen reading than clumsy serif fonts like roboto slab).

3. Clicking the top-left dub logo directs to "http://code.dlang.org/packages/" which is 404.

4. List of available versions for a package is broken: the most recent version is repeated multiple times and is not a hyperlink.

Also, some parts of READMEs are not rendered the way they are on github, like: nested lists, [ ]/[x] progress ticks, syntax highlighting in code snippets.

On Tuesday, 24 May 2016 at 22:59:24 UTC, Adrian Matoga wrote:
> (...)
> 1. The font is much thinner than on dlang.org main site

PR: https://github.com/dlang/dub-registry/pull/156

> 3. Clicking the top-left dub logo directs to "http://code.dlang.org/packages/" which is 404.

PR: https://github.com/dlang/dub-registry/pull/157