NYCJUG/2009-12-10

J 7.01, GTK, bug reporting, terse code, programming languages, tele-conference

Meeting Agenda for NYC JUG 20090811

1. Beginner's regatta: How should we report bugs in J?
See "HowDoWeReportBugsInJ.doc".

2. Show-and-tell: Chris Burke on the next release of J: 7.01.

3. Advanced topics: arguments for advantages of terse code - see
"ShortIsSweetSelections.doc".

4. Learning, teaching and promoting J: Language comparisons - see
"Comparing Different Programming Languages.doc",
"EmpiricalComparisonOfProgrammingLangs_jccpprt_computer2000.pdf", and
"Python vs Clojure - measuring lines of code.doc".

Proceedings

We had the first global NYCJUG meeting - our tele-conference included participants from the Philipines, New Zealand, California, and various other American states.

Some technical glitches slowed us down but we eventually were able to chat with Jugglers from around the world and see a demo of some very cool new directions for the upcoming release of J.

Beginner's Regatta: Bug Reporting

We framed this question with an e-mail from Dan Bron, in which he proposed: What is the preferred way to report bugs? So far as I know, the 3 venues are:

  1.  This forum, e.g. [1]
  2.  The wiki, e.g. at  http://www.jsoftware.com/jwiki/System/Interpreter/Bugs
  3.   Trac, i.e. at  http://www.jsoftware.com/trac/base

The Trac page says it supercedes the Wiki -- is that statement true, and currently in force?  If so, why does it require logging in, and is there a public login?

 Is Trac also preferred to reporting bugs here?  Is anyone tasked with making sure any bugs reported here make it into Trac (e.g. [1])?

Finally, since J development is essentially federated (Roger on engine, Chris on scripts, Eric on FE, Oleg/Henry/Ric/others on various Addons), does the preferred venue change depending on who owns responsibility for the buggy component?  Do individual contributors have preferences?

-Dan

[1]  http://www.jsoftware.com/pipermail/programming/2009-December/017165.html

While it was generally agreed that the bulk of the work should be shouldered by a bug-tracking system like Trac, there was debate on whether bugs should initially be reported there, and reported to the Forum, or reported on the J-Programming Forum and moved to Trac as necessary. While, in the meeting there seemed to be a consensus toward first reporting on the Forum, Ric Sherlock made the following argument for the other way around. The main argument for first reporting on the Forum is to filter spurious bugs which are more mis-understandings of how J is supposed to work than actual bugs. Ric, however, argues as follows.

I think there are significant advantages to having the bugs entered in Trac directly by the reporter where possible - apart from anything it will share the load. However I think there is also value in having a record of spurious bugs too. Once they have been established as spurious, the ticket can be closed as "not a bug".  It will then be filtered from the list of Active bugs.

Trac bug reporting is currently set up to enable you to assign a bug to a Component. Components map to Addons or areas of the System (eg. Engine, Help docs, JfC ...) Those components are in turn mapped to the responsible person. Once email notification is enabled, that person will be notified that a bug has been logged (and a copy could be sent to the appropriate forum).

> Also, I don't think we'll ever convince everyone to stop reporting bugs
> on the Forum anyway (newcomers who don't know about Trac, or those who
> don't want to bother with a web interface, or who are worried they'd report a
> non-bugs, etc), so we'd need the Forum-to-Trac migration process,
> anyway.

I agree but perhaps rather than have it all one way or the other, both avenues can be available? Logging the bug via Trac might be the recommended/preferred option but one or more users could be appointed as bug admins (they could be called "buggers" ?! ;-) ) who would ensure that bugs reported directly to the forum were also entered in Trac.

> Another option is to provide public credentials, so that one needn't
> sign up to report bugs; that would remove some complexities and barriers (and
> raise other questions).

I think there would be a security issue with this, much in the same way as there is with the wiki. You end up with all sorts of junk posted if you do not restrict access.

Show-and-Tell: the New J

There's a lot to cover here, so let's just start with a summary from Dan on J-Beta:

Message: 5
Date: Sun, 13 Dec 2009 21:21:11 -0500
From: "Dan Bron" <j@bron.us>
Subject: Re: [Jbeta] jhsserver
To: "'Beta forum'" <beta@jsoftware.com>
Message-ID: <001301ca7c64$1a947070$4fbd5150$@us>
Content-Type: text/plain;       charset="us-ascii"

Bill Lam
> Didn't Chris demonstrate how to do that? (I missed that event)

For those who missed the event:

       *  There will be one more version of J6 before J7 is released: J6.03
       *  J6.03 will have the new J7 engine (J.dll) but the current front
ends (j.exe, j.jar etc)
       *  In J7, the engine will be packaged as an executable rather than a
DLL.
       *  This executable will essentially be a combination of what j.dll
and jconsole are today.
       *  The current frontends are deprecated in J7.
       *  The primary FE in J7 will be GTK-based. And it's VERY cool.
       *  JHS will also be available in J7
       *  Some current functionality may not make it into J7, e.g. J COM
servers.

-Dan

Advanced topics: Arguments for Advantages of Terse Code

More on this later when I put up slides from my talk to the Kdb+ Users Group.