On Thu, Sep 12, 2013 at 08:39:11AM +0200, Jacob Carlborg wrote:
> On 2013-09-12 00:50, H. S. Teoh wrote:
> 
> >But this is JS we're talking about. What happens, boys and gals, when the JS interpreter encounters an uncaught error? That's right, it logs an error message to the error console (which is hidden by default in most browsers), and silently fails without any warning, and then the rest of the site's scripts (hooked to various event handlers) CONTINUE RUNNING AS IF NOTHING HAPPENED.
> 
> My experience is that if a JavaScript fails, somehow, JavaScript fill stop working all together on the site. But that's perhaps not the case if an exception is thrown. But rather if you're trying to use a variable or similar that doesn't exist.
[...]

Well, you may be right, but at the time I was working on a YUI-based framework, and I discovered that either YUI, or the way the framework initializes YUI (I didn't write the base framework code so I don't know for sure), has some kind of default exception-catching code that catches such exceptions and then proceeds to *ignore* it. It does terminate the current execution thread, mind you, but all the other event handlers and hooks are still active, and the rest of the code attached to them will continue running despite the fact that something has catastrophically failed. Which, of course, means that now some object(s) are in an invalid state due to the previous failure, but the code is completely unaware of this situation and continue barging ahead and doing stuff, until it encounters the bad objects, and then random failures happen (which all get swallowed by the default catcher, thus promulgating the problem).

But either way, the behaviour is equally bad. If JS stops executing upon encountering an exception, then you just randomly get a blank page (when the bug is triggered) with no helpful indication whatsoever what went wrong. If it continues executing, then you get random failures for no apparent reason. Both are equally hard to debug, and both could've been avoided had JS had *sane* handling of errors in the first place.


T

-- 
Gone Chopin. Bach in a minuet.

On 2013-09-12 15:37, H. S. Teoh wrote:

> Well, you may be right, but at the time I was working on a YUI-based
> framework, and I discovered that either YUI, or the way the framework
> initializes YUI (I didn't write the base framework code so I don't know
> for sure), has some kind of default exception-catching code that catches
> such exceptions and then proceeds to *ignore* it. It does terminate the
> current execution thread, mind you, but all the other event handlers and
> hooks are still active, and the rest of the code attached to them will
> continue running despite the fact that something has catastrophically
> failed. Which, of course, means that now some object(s) are in an
> invalid state due to the previous failure, but the code is completely
> unaware of this situation and continue barging ahead and doing stuff,
> until it encounters the bad objects, and then random failures happen
> (which all get swallowed by the default catcher, thus promulgating the
> problem).
>
> But either way, the behaviour is equally bad. If JS stops executing upon
> encountering an exception, then you just randomly get a blank page (when
> the bug is triggered) with no helpful indication whatsoever what went
> wrong. If it continues executing, then you get random failures for no
> apparent reason. Both are equally hard to debug, and both could've been
> avoided had JS had *sane* handling of errors in the first place.

Absolutely, I agree. I have seen JavaScript errors on Github from time to time. But it seems like everything continue to work as expected.

-- 
/Jacob Carlborg

> We're considering making dub the official package manager for D. What do
> you all think?

Please let's do it.

At first I was like 'why would I need that?'. But soon I ported all my (alive) projects to dub and never came back.

Since it can also generate projects for IDEs, it's also a great simplifier of projects. I've noted that it dramatically increased my likeliness to use and discover other's packages.

I am all in favor of making dub *the* D package manager to use. pypi is awesome, and we've got something which can be just as awesome. Let's do it.

On the subject of YAML. I've tried it out a few times. The syntax for JSON can be described in 1-2 pages, on json.org's front page. The syntax for YAML requires a 50-100 page document to describe. That should be enough to tell you not to use it.

On Thursday, September 12, 2013 22:02:15 w0rp wrote:
> On the subject of YAML. I've tried it out a few times. The syntax for JSON can be described in 1-2 pages, on json.org's front page. The syntax for YAML requires a 50-100 page document to describe. That should be enough to tell you not to use it.

While, I agree in principle, I would point out that what's on json.org is oversimplified and is not a valid spec. You really need to read the RFC if you want to get it right, and that has about 9 pages of actual content:

http://www.ietf.org/rfc/rfc4627.txt?number=4627

So, you're comparing a basic explanation of JSON to a full-on spec for YAML. Now, the YAML 1.2 spec does have about 77 pages of actual content:

http://yaml.org/spec/1.2/spec.pdf

So, you're not completely off base in your comparison (YAML _is_ way more complicated), but to properly specify JSON requires a lot more pages than your post indicates.

- Jonathan M Davis

On Thursday, 12 September 2013 at 20:18:35 UTC, Jonathan M Davis
wrote:
> On Thursday, September 12, 2013 22:02:15 w0rp wrote:
>> On the subject of YAML. I've tried it out a few times. The syntax
>> for JSON can be described in 1-2 pages, on json.org's front page.
>> The syntax for YAML requires a 50-100 page document to describe.
>> That should be enough to tell you not to use it.
>
> While, I agree in principle, I would point out that what's on json.org is
> oversimplified and is not a valid spec. You really need to read the RFC if you
> want to get it right, and that has about 9 pages of actual content:
>
> http://www.ietf.org/rfc/rfc4627.txt?number=4627
>
> So, you're comparing a basic explanation of JSON to a full-on spec for YAML.
> Now, the YAML 1.2 spec does have about 77 pages of actual content:
>
> http://yaml.org/spec/1.2/spec.pdf
>
> So, you're not completely off base in your comparison (YAML _is_ way more
> complicated), but to properly specify JSON requires a lot more pages than your
> post indicates.
>
> - Jonathan M Davis

That's a much more fair comparison. Thanks.

Am 11.09.2013 18:14, schrieb Brad Anderson:
> On Wednesday, 11 September 2013 at 14:11:11 UTC, John Colvin wrote:
>> Why not YAML? It's cleaner than JSON and is very widely known.
>
> YAML is nice but can be surprisingly tricky to write by hand sometimes
> (especially for people not used to significant whitespace).
>
> Here's the discussion about JSON vs. YAML vs. SDL on the dub forum:
>
> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

I have to admit that looking at the examples *now* leaves me with a strong distaste for YAML. That wasn't the case in the beginning, but now, after not having looked at any YAML document since then and even with only the simplest syntax constructs used, it just looks confusing to me.

Some points that stand out:

 - Built-in field names and user defined dictionary key (can) look the
   same and can be quite confusing (my initial reaction to the
   "sub-package:" line in the example was "Hmm.. what kind of command
   is *that*?")

 - Indentation based scoping is much less explicit than braces. Someone
   who has never seen the format may well think that it's just visual
   formatting and has to read up on it first.

 - It still has the deep nesting of the JSON format

 - The complexity of the specification is a bit of a turn-off, too

Having said that, YAML for sure is a nice format for many things and considerably more powerful in some areas than f.ex. SDL, but here I think the focus should be on the most concise and intuitive textual representation and IMO SDL does a better job there. More advanced features of YAML, if needed, can also easily be simulated with SDL.

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
> We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project.
>
> We're considering making dub the official package manager for D. What do you all think?
>

Several remarks (I'm a dub newbie, so it is mostly conditional stuff) :
 - Can we manage repositories ? For instance can I use my company repo instead of code.dlang.org ? Can I use several repositories with some kind of priorisation ?
 - How does the tool handle several version of a package ?
 - What is the process to get some code on code.dlang.org ? We must settle something if this have to go "official".
 - What is the dependance management strategy used ? How does it resolve conflicts ?

Am 13.09.2013 12:00, schrieb deadalnix:
> On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
>> We've been experimenting with http://code.dlang.org for a while and
>> things are going well. In particular Sönke has been very active about
>> maintaining and improving it, which brings further confidence in the
>> future of the project.
>>
>> We're considering making dub the official package manager for D. What
>> do you all think?
>>
>
> Several remarks (I'm a dub newbie, so it is mostly conditional stuff) :
>   - Can we manage repositories ? For instance can I use my company repo
> instead of code.dlang.org ? Can I use several repositories with some
> kind of priorisation ?

It supports specifying a list of registries that is searched linearly for packages in its config file (or as a command line argument) - I think I still need to document that, though.

The registry currently supports only GitHub and Bitbucket repositories to source packages from, but that can be easily extended by implementing the "Repository" interface.

>   - How does the tool handle several version of a package ?

In the current registry implementation, git tags of the form vX.Y.Z[postfix] are taken as the available versions. When specifying dependencies it's then possible to use relational operators to specify a range of acceptable versions, of which the newest is used. Things like the version pinning mechanism proposed by Jacob can still improve things in this area.

>   - What is the process to get some code on code.dlang.org ? We must
> settle something if this have to go "official".

My idea (the status quo) is to keep that as open as possible. Anyone can register an account and register his/her repository. Package names are reserved on a first-come-first-serve basis. This process would then be augmented with community votes, automatic package deprecation and sporadic moderation to keep everything clean in the long term.


>   - What is the dependance management strategy used ? How does it
> resolve conflicts ?

There are basically three areas where things can conflict AFAICS:

 - Accepted version ranges for packages that are referenced by multiple
   other packages: Here the best version that satisfies all given
   ranges is used if possible, otherwise error out

 - Selected configuration for a package: This is resolved to the first
   possible set of configurations if possible, otherwise error out
   (this is a bit more complex due to the platform playing a role in
   configuration selection)

 - Conflicts in code (i.e. module/package name clashes) - This is
   currently not handled, but there have been discussions about that
   topic:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1/

On Friday, 13 September 2013 at 11:55:42 UTC, Sönke Ludwig wrote:
>>  - What is the process to get some code on code.dlang.org ? We must
>> settle something if this have to go "official".
>
> My idea (the status quo) is to keep that as open as possible. Anyone can register an account and register his/her repository. Package names are reserved on a first-come-first-serve basis. This process would then be augmented with community votes, automatic package deprecation and sporadic moderation to keep everything clean in the long term.

I think AUR (Arch Linux Repository) model is very successful one and worth paying attention to when it comes to source packages. Other than voting it also has `out-of-date` flagging by users which helps to noticed abandoned packages fast. There is also small group of trusted users who processes requests for package ownership transfer / package merging via mail list. Any suspicious / malicious package get processed in a similar way. Other than that it is very anarchic environment and still works damn well - AUR package count is now more than 40 000 and Arch Linux is pretty young distro.