From wmorgan-ditz at masanjin.net  Tue Jun  3 16:41:04 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 03 Jun 2008 13:41:04 -0700
Subject: [ditz-talk] [PATCH] make HookManager a class instead of a module
Message-ID: <1212525523-sup-1193@entry>

---
For the hooks branch. This makes things more Rubyesque.

 lib/hook.rb |   40 +++++++++++++++++++++-------------------
 1 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/lib/hook.rb b/lib/hook.rb
index 66403d6..0bc5bb9 100644
--- a/lib/hook.rb
+++ b/lib/hook.rb
@@ -1,40 +1,43 @@
 module Ditz
-  module HookManager
-    module_function
+  class HookManager
+    def initialize
+      @descs = {}
+      @blocks = {}
+    end
 
-    @@descs = {}
-    @@blocks = {}
+    @@instance = nil
+    def self.method_missing m, *a, &b
+      @@instance ||= self.new
+      @@instance.send m, *a, &b
+    end
 
     def register name, desc
-      raise "Ditz::HookManager.register needs a symbol not #{name.inspect}" unless name.is_a? Symbol
-      @@descs[name] = desc
-      @@blocks[name] = []
+      @descs[name] = desc
+      @blocks[name] = []
     end
 
     def on *names, &block
-      for name in names do
-        raise "unregistered hook #{name.inspect}" unless @@descs[name]
-        @@blocks[name] << block
+      names.each do |name|
+        raise "unregistered hook #{name.inspect}" unless @descs[name]
+        @blocks[name] << block
       end
     end
 
     def run name, *args
-      raise "unregistered hook #{name.inspect}" unless @@descs[name]
+      raise "unregistered hook #{name.inspect}" unless @descs[name]
       blocks = hooks_for name
       return false if blocks.empty?
-      for block in blocks do
-        block[*args]
-      end
+      blocks.each { |block| block[*args] }
       true
     end
 
     def print_hooks f=$stdout
 puts <<EOS
-Ditz have #{@@descs.size} registered hooks:
+Ditz has #{@descs.size} registered hooks:
 
 EOS
 
-      @@descs.map{ |k,v| [k.to_s,v] }.sort.each do |(name, desc)|
+      @descs.map{ |k,v| [k.to_s,v] }.sort.each do |name, desc|
         f.puts <<EOS
 #{name}
 #{"-" * name.length}
@@ -46,13 +49,12 @@ EOS
     def enabled? name; !hooks_for(name).empty? end
 
     def hooks_for name
-      if @@blocks[name].nil? || @@blocks[name].empty?
+      if @blocks[name].nil? || @blocks[name].empty?
         fns = File.join(ENV['HOME'], '.ditz', 'hooks', '*.rb') 
         Dir[fns].each { |fn| load fn }
       end
 
-      @@blocks[name] || []
+      @blocks[name] || []
     end
   end
-
 end
-- 
1.5.4.rc2.60.gb2e62-dirty
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Tue Jun  3 17:24:10 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 03 Jun 2008 14:24:10 -0700
Subject: [ditz-talk] [PATCH] make HookManager a class instead of a module
In-Reply-To: <1212525523-sup-1193@entry>
References: <1212525523-sup-1193@entry>
Message-ID: <1212528244-sup-1961@entry>

Reformatted excerpts from William Morgan's message of 2008-06-03:
> For the hooks branch. This makes things more Rubyesque.

Actually since that's in master already, I'll just patch this directly.
No need for excessive bureaucracy.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Tue Jun  3 18:24:50 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 03 Jun 2008 15:24:50 -0700
Subject: [ditz-talk] release 0.3
Message-ID: <1212531825-sup-6599@entry>

Hi all,

I've resolved all the issues for release 0.3 and synced master and edge.
I'll probably cut a release some time today or tomorrow. If you have a
favorite feature, now's the time to double-check it still works. :)
-- 
William <wmorgan-ditz at masanjin.net>

From why at whytheluckystiff.net  Tue Jun  3 22:19:37 2008
From: why at whytheluckystiff.net (_why)
Date: Tue, 3 Jun 2008 21:19:37 -0500
Subject: [ditz-talk] release 0.3
In-Reply-To: <1212531825-sup-6599@entry>
References: <1212531825-sup-6599@entry>
Message-ID: <20080604021936.GO70833@beekeeper.hobix.com>

On Tue, Jun 03, 2008 at 03:24:50PM -0700, William Morgan wrote:
> I've resolved all the issues for release 0.3 and synced master and edge.
> I'll probably cut a release some time today or tomorrow. If you have a
> favorite feature, now's the time to double-check it still works. :)

Very nicely done.  The hooks work just great.  It's good to see
ISSUE_TO_FN gone and all the clean up bin/ditz.

_why

From devinw at gmail.com  Wed Jun  4 18:08:00 2008
From: devinw at gmail.com (Devin Walters)
Date: Wed, 4 Jun 2008 17:08:00 -0500
Subject: [ditz-talk] release 0.3
In-Reply-To: <1212531825-sup-6599@entry>
References: <1212531825-sup-6599@entry>
Message-ID: <be5f056e0806041508n45fbf3d6ifa5566c471691c23@mail.gmail.com>

> I've resolved all the issues for release 0.3 and synced master and edge.
> I'll probably cut a release some time today or tomorrow. If you have a
> favorite feature, now's the time to double-check it still works. :)

I don't mean to junk up your nice mailing list, but I can't thank you
enough for the work you're doing on ditz.  I absolutely love it.

-- 
Devin


Random Fortune:
  I don't think anyone should write their
  autobiography until after they're dead. -Samuel
  Goldwyn

From wmorgan-ditz at masanjin.net  Wed Jun  4 18:09:01 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 04 Jun 2008 15:09:01 -0700
Subject: [ditz-talk] [ANN] ditz 0.3 released
In-Reply-To: <1212531825-sup-6599@entry>
References: <1212531825-sup-6599@entry>
Message-ID: <1212617287-sup-2975@entry>

Ditz version 0.3 has been released!

* <http://ditz.rubyforge.org>

Ditz is a simple, light-weight distributed issue tracker designed to work with
distributed version control systems like darcs and git. Ditz maintains an issue
database directory on disk, with files written in a line-based and human-
editable format. This directory is kept under version control alongside
project code. Changes in issue state is handled by version control like code
change: included as part of a commit, merged with changes from other
developers, conflict-resolved in the standard manner, etc.

Ditz provides a simple, console-based interface for creating and updating the
issue database files, and some rudimentary HTML generation capabilities for
producing world-readable status pages. It offers no central public method of
bug submission.

Synopsis:

# set up project. creates the bugs.yaml file.
1. ditz init
2. ditz add-release

# add an issue
3. ditz add

# where am i?
4. ditz status
5. ditz todo

# do work
6. write code
7. ditz close <issue-id>
8. commit
9. goto 3

# finished!
10. ditz release <release-name>

Changes:

## 0.3 / 2008-06-04
* readline support for all text entry
* hook system. Use ditz -l to see possible hooks.
* new commands: archive, shortlog, set-component
* improved commands: log, assign, add-release
* new issue type: 'tasks'
* 'ditz' by itself shows the todo list
* zsh tab completion for subcommands
* local config can now specify bugs directory location
* issue name interpolation now on all issue fields
* bugfix: various HTML generation bugs
* bugfix: ditz now works from project subdirectories
* bugfix: removed UNIX-specific environment variable assumptions

* <http://ditz.rubyforge.org>
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Wed Jun  4 18:13:15 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 04 Jun 2008 15:13:15 -0700
Subject: [ditz-talk] release 0.3
In-Reply-To: <be5f056e0806041508n45fbf3d6ifa5566c471691c23@mail.gmail.com>
References: <1212531825-sup-6599@entry>
	<be5f056e0806041508n45fbf3d6ifa5566c471691c23@mail.gmail.com>
Message-ID: <1212617540-sup-4290@entry>

Reformatted excerpts from Devin Walters's message of 2008-06-04:
> I don't mean to junk up your nice mailing list, but I can't thank you
> enough for the work you're doing on ditz.  I absolutely love it.

Effusive praise is always allowed on the list. :)

Thanks!
-- 
William <wmorgan-ditz at masanjin.net>

From nicolas.pouillard at gmail.com  Fri Jun  6 07:38:42 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Fri, 06 Jun 2008 13:38:42 +0200
Subject: [ditz-talk] [PATCH] make HookManager a class instead of a module
In-Reply-To: <1212528244-sup-1961@entry>
References: <1212525523-sup-1193@entry> <1212528244-sup-1961@entry>
Message-ID: <1212752313-sup-3271@ausone.inria.fr>

Excerpts from William Morgan's message of Tue Jun 03 23:24:10 +0200 2008:
> Reformatted excerpts from William Morgan's message of 2008-06-03:
> > For the hooks branch. This makes things more Rubyesque.
> 
> Actually since that's in master already, I'll just patch this directly.
> No need for excessive bureaucracy.

I agree :)

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080606/3ddc84ca/attachment.bin>

From akaihol+ditz at ambitone.com  Fri Jun  6 06:46:24 2008
From: akaihol+ditz at ambitone.com (Antti Kaihola)
Date: Fri, 6 Jun 2008 13:46:24 +0300
Subject: [ditz-talk] [PATCH] empty comment bug
Message-ID: <20080606134624.4eed061a@veli>

---
 ...e-15c2b94d3e828811815b0baa1f5efdce7d6bba54.yaml |   51 ++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 bugs/issue-15c2b94d3e828811815b0baa1f5efdce7d6bba54.yaml

diff --git a/bugs/issue-15c2b94d3e828811815b0baa1f5efdce7d6bba54.yaml b/bugs/issue-15c2b94d3e828811815b0baa1f5efdce7d6bba54.yaml
new file mode 100644
index 0000000..24d8417
--- /dev/null
+++ b/bugs/issue-15c2b94d3e828811815b0baa1f5efdce7d6bba54.yaml
@@ -0,0 +1,51 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: unmodified comment from external editor results in an invalid log_events entry
+desc: |-
+  In ditz 0.2, if an external editor is launched by the /edit command
+  but no comment is entered, an invalid log event entry is created.  The
+  'ditz log' command throws the following error message after displaying
+  the log entry:
+  
+  date  : Tue Jun 03 11:03:18 +0300 2008 (25 minutes ago)
+  author: Antti Kaihola <akaihol+ditz at ambitone.com>
+  
+    test-3: A test issue
+    changed status from unstarted to in_progress
+    
+  /var/lib/gems/1.8/gems/ditz-0.2/lib/operator.rb:455:in `log': undefined method `blank?' for nil:NilClass (NoMethodError)
+  	from /var/lib/gems/1.8/gems/ditz-0.2/lib/operator.rb:444:in `each'
+  	from /var/lib/gems/1.8/gems/ditz-0.2/lib/operator.rb:444:in `log'
+  	from /var/lib/gems/1.8/gems/ditz-0.2/lib/operator.rb:86:in `send'
+  	from /var/lib/gems/1.8/gems/ditz-0.2/lib/operator.rb:86:in `do'
+  	from /var/lib/gems/1.8/gems/ditz-0.2/bin/ditz:83
+  
+  The problem is caused by the missing double quotes in the YAML file
+  for the empty comment of the log entry (see last line in the example
+  below):
+  
+  log_events: 
+  - - 2008-06-03 08:01:22.237356 Z
+    - Antti Kaihola <akaihol+ditz at ambitone.com>
+    - created
+    - ""
+  - - 2008-06-03 08:03:18.389444 Z
+    - Antti Kaihola <akaihol+ditz at ambitone.com>
+    - changed status from unstarted to in_progress
+    - 
+  
+  If the double quotes are added manually, everything works as expected.
+type: :bugfix
+component: ditz
+release: 
+reporter: Antti Kaihola <akaihol+ditz at ambitone.com>
+status: :unstarted
+disposition: 
+creation_time: 2008-06-03 10:55:16.253594 Z
+references: []
+
+id: 15c2b94d3e828811815b0baa1f5efdce7d6bba54
+log_events: 
+- - 2008-06-03 10:55:18.004568 Z
+  - Antti Kaihola <akaihol+ditz at ambitone.com>
+  - created
+  - ""
-- 
1.5.4.3

From wmorgan-ditz at masanjin.net  Sat Jun  7 19:23:17 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Sat, 07 Jun 2008 16:23:17 -0700
Subject: [ditz-talk] [PATCH] empty comment bug
In-Reply-To: <20080606134624.4eed061a@veli>
References: <20080606134624.4eed061a@veli>
Message-ID: <1212880948-sup-3175@entry>

Reformatted excerpts from Antti Kaihola's message of 2008-06-06:
> +  In ditz 0.2, if an external editor is launched by the /edit command
> +  but no comment is entered, an invalid log event entry is created.

I believe this has been fixed in 0.3. Can you confirm?

Thanks for my first bug-report-as-patch!
-- 
William <wmorgan-ditz at masanjin.net>

From dan at haxney.org  Sun Jun  8 22:36:48 2008
From: dan at haxney.org (Daniel Hackney)
Date: Sun, 8 Jun 2008 22:36:48 -0400
Subject: [ditz-talk]  Operator Arguments
Message-ID: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>

I am currently working on the "operator-arguments" branch on Gitorious, and have
a whole lot more work that isn't yet there, but I am wondering about some
development decisions.

Since it is a fairly large change (operator.rb will be almost completely
rewritten), I had some questions about what the best way to submit it would be.

  1. Would a single patch of the whole change, rebased off of the current head
     be best, or would a patch for each operator be preferred?

  2. Is it still a good idea to have all of the operators in the same big file,
     or could I break them out into one file per operation (in a subdirectory
     most likely)?

  3. Would it be okay to drop the dependency on Trollop and add CmdParse
     [cmdparse.rubyforge.org], which is also packaged as a Gem?

One of my goals is to be able to create a "batch mode" where some option (like
"-b") could be passed to ditz to tell it never to ask the user any questions,
for use with a frontend like emacs. This would not have to happen with the first
revision of the operator-argument branch, but it could be useful.

The patch needs a whole bunch more cleaning up before inclusion (not the least
of which is checking whether it actually all works), but I'll push what I have
so far to Gitorious so anyone can take a look at it. Keep in mind that I haven't
yet modified anything outside of operator.rb, so nothing else uses the new
functionality, so the whole thing will not work, but it could be worth at least
a glance.

Thanks for a very useful program!

--
Daniel M. Hackney

From wmorgan-ditz at masanjin.net  Mon Jun  9 18:53:49 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 09 Jun 2008 15:53:49 -0700
Subject: [ditz-talk] Operator Arguments
In-Reply-To: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
References: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
Message-ID: <1213049896-sup-8944@entry>

Reformatted excerpts from Daniel Hackney's message of 2008-06-08:
> I am currently working on the "operator-arguments" branch on
> Gitorious, and have a whole lot more work that isn't yet there, but I
> am wondering about some development decisions.

Great! I'd love to have per-operator arguments.

> 1. Would a single patch of the whole change, rebased off of the
> current head be best, or would a patch for each operator be preferred?

A patch for each logical set of changes, preferrably with each resulting
in a working system. (To the extent that it's not overly cumbersome.)

> 2. Is it still a good idea to have all of the operators in the same
> big file, or could I break them out into one file per operation (in a
> subdirectory most likely)?

I'd like to keep small ones in one file, but larger ones could be broken
out.

> 3. Would it be okay to drop the dependency on Trollop and add CmdParse
> [cmdparse.rubyforge.org], which is also packaged as a Gem?

Definitely not. I wrote Trollop because cmdparse and all the other Ruby
option parsers are clumsy and Java-esque.

I actually have a reasonably simple plan for inserting operator
arguments into ditz.

1. Patch trollop so that it takes a set of words which stop argument
   processing at that point.
2. In ditz, give trollop the set of commands as that set of words.
3. For each command that takes arguments, re-invoke trollop with the set
   of command-specific arguments.

> One of my goals is to be able to create a "batch mode" where some
> option (like "-b") could be passed to ditz to tell it never to ask the
> user any questions, for use with a frontend like emacs. This would not
> have to happen with the first revision of the operator-argument
> branch, but it could be useful.

I'd love to have this too. Most of the user input (besides asking for
comments) is actually invoked programmatically by
ModelObject.create_interactively, so having e.g. a set of commandline
arguments that specify the needed text is fairly straight-forward.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Thu Jun 12 22:21:08 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 12 Jun 2008 19:21:08 -0700
Subject: [ditz-talk] recently modified issues in index.html
Message-ID: <1213323633-sup-8797@entry>

I've added a little list of recently-modified issues to the index.html.
Check it out:

http://ditz.rubyforge.org/ditz/

Now that's fancy!
-- 
William <wmorgan-ditz at masanjin.net>

From Daniel_Hackney at brown.edu  Mon Jun 16 21:03:21 2008
From: Daniel_Hackney at brown.edu (Daniel Hackney)
Date: Mon, 16 Jun 2008 21:03:21 -0400
Subject: [ditz-talk] Operator Arguments
In-Reply-To: <1213049896-sup-8944@entry>
References: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
	<1213049896-sup-8944@entry>
Message-ID: <ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>

William Morgan <wmorgan-ditz at masanjin.net> wrote:
> > 1. Would a single patch of the whole change, rebased off of the
> > current head be best, or would a patch for each operator be
> > preferred?
>
> A patch for each logical set of changes, preferrably with each
> resulting in a working system. (To the extent that it's not overly
> cumbersome.)

I don't know how much that would be possible, since I am rewriting how
arguments are handed to the operators, which is pretty invasive. Short
of writing a compatibility layer to allow either method of argument
parsing to be used (which I think is a waste of time), I think the best
way forward is just to squash the whole thing into a single commit and
rebase off of the current master (or edge).

> > 2. Is it still a good idea to have all of the operators in the same
> > big file, or could I break them out into one file per operation (in
> > a subdirectory most likely)?
>
> I'd like to keep small ones in one file, but larger ones could be
> broken out.

Since there is the "short circuit" functionality of the `--commands'
argument, it may make sense to have a small file with the information
about the commands and then all of the code separate. Then again, since
the amount of time it takes to parse some extra classes is probably
pretty minimal, worrying too much about this is probably a waste of
effort.

> > 3. Would it be okay to drop the dependency on Trollop and add
> > CmdParse [cmdparse.rubyforge.org], which is also packaged as a Gem?
>
> Definitely not. I wrote Trollop because cmdparse and all the other
> Ruby option parsers are clumsy and Java-esque.

I haven't found CmdParse to be that clumsy. I create a class for each
command which has an "execute" method which is called when its command
is found and passed the command line options not consumed by the
argument parser.

Likewise, I have been using the "optparse" library distributed with Ruby
for the parsing of the arguments. It certainly isn't perfect, but it
works and is there, and I don't feel like it is lacking crucial
functionality. I haven't taken a very close look at Trollop yet, and I
don't doubt that it is superior, but CmdParse/OptParse works and is
available.

I think what I'll do is finish writing it with CmdParse/OptParse,
present it to you, and if you think that it is still to clumsy, I can
look at adding operator arguments to Trollop and then converting my
patch to use that.

> I actually have a reasonably simple plan for inserting operator
> arguments into ditz.
>
> 1. Patch trollop so that it takes a set of words which stop argument
>    processing at that point.

Alternatively, CmdParse has the option to wrap around an existing
argument parser. We could write a wrapper for Trollop and use the
command-parsing ability of CmdParse without too much trouble.

> 2. In ditz, give trollop the set of commands as that set of words.
> 3. For each command that takes arguments, re-invoke trollop with the
>    set of command-specific arguments.

Sounds good. That's basically what I am doing now, only with the
CmdParse/OptParse combo.

> > One of my goals is to be able to create a "batch mode" [...]
>
> I'd love to have this too. Most of the user input (besides asking for
> comments) is actually invoked programmatically by
> ModelObject.create_interactively, so having e.g. a set of commandline
> arguments that specify the needed text is fairly straight-forward.

>From what I could tell, all you really need to do is to pass enough
stuff in the ":with" hash option to keep it from asking anything. It
might be nice to have some list of the options each operator needs in
order to run in batch mode and fail if they are not met.

For example, many commands take a comment message, but they can either
take a string on the command line, a filename to read from, or the "no
comment" option. It would need only one, since each of them satisfy the
"comment" option.

That could come in a separate patch, though.

--
Daniel M. Hackney
Brown University
Box 761
Providence, RI, 02912
Cell: (610) 368-7607

From wmorgan-ditz at masanjin.net  Tue Jun 17 12:50:20 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 17 Jun 2008 09:50:20 -0700
Subject: [ditz-talk] Operator Arguments
In-Reply-To: <ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>
References: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
	<1213049896-sup-8944@entry>
	<ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>
Message-ID: <1213719801-sup-5255@entry>

Reformatted excerpts from Daniel Hackney's message of 2008-06-16:
> Since there is the "short circuit" functionality of the `--commands'
> argument, it may make sense to have a small file with the information
> about the commands and then all of the code separate. Then again,
> since the amount of time it takes to parse some extra classes is
> probably pretty minimal, worrying too much about this is probably a
> waste of effort.

I also think it would be wasted effort. The --commands case is special
and it makes sense to make that as fast as reasonably possible.
Everything else should stay as it is.

> I think what I'll do is finish writing it with CmdParse/OptParse,
> present it to you, and if you think that it is still to clumsy, I can
> look at adding operator arguments to Trollop and then converting my
> patch to use that.

It's fine if you want to continue down that route, but I will tell you
now that I not accept patches that replace Trollop.

The good news is that I've just released a new version of Trollop (1.8)
which has a "stop_on" method that halts option parsing when the given
tokens are encountered. If you want to try and plug that into ditz,
here's the interface I'd like to see:

1. Have the "operation" method take an optional block where you can
   specify per-operation arguments, like so:

   operation :todo, "Generate todo list", :magic_release do
     opt :all, "Show all items, not just incomplete ones"
   end

2. Make it so that the config hash that's passed in to operation
   methods has both the config file options and the command-specific
   options mashed into the same namespace. (At some point I'm going to
   mash $opts into there too so there are no more global variables.) If
   there's a namespace conflict, options should trump config file.

3. For operations that don't have any options, nothing should have to
   change.

This is something I've been thinking about for a while. You're welcome
to take a stab at it. Probably best would be one patch that adds that
functionality, and then a patch per operation to add arguments and their
related behavior.

> From what I could tell, all you really need to do is to pass enough
> stuff in the ":with" hash option to keep it from asking anything. It
> might be nice to have some list of the options each operator needs in
> order to run in batch mode and fail if they are not met.

The list of requirements will have to be generated from the model
objects, since they're the ones that have that information. (And in the
future the set of fields will be modifiable by the user.) It probably
makes sense to have a Model.create_noninteractively that dies with
incomplete information rather than prompting. Haven't really thought it
through...

This should definitely be a separate patch, though.
-- 
William <wmorgan-ditz at masanjin.net>

From nicolas.pouillard at gmail.com  Tue Jun 17 15:01:26 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Tue, 17 Jun 2008 21:01:26 +0200
Subject: [ditz-talk] Operator Arguments
In-Reply-To: <ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>
References: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
	<1213049896-sup-8944@entry>
	<ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>
Message-ID: <1213729148-sup-908@ausone.local>

Excerpts from Daniel Hackney's message of Tue Jun 17 03:03:21 +0200 2008:
> William Morgan <wmorgan-ditz at masanjin.net> wrote:
> > > 1. Would a single patch of the whole change, rebased off of the
> > > current head be best, or would a patch for each operator be
> > > preferred?
> >
> > A patch for each logical set of changes, preferrably with each
> > resulting in a working system. (To the extent that it's not overly
> > cumbersome.)
> 
> I don't know how much that would be possible, since I am rewriting how
> arguments are handed to the operators, which is pretty invasive. Short
> of writing a compatibility layer to allow either method of argument
> parsing to be used (which I think is a waste of time), I think the best
> way forward is just to squash the whole thing into a single commit and
> rebase off of the current master (or edge).
> 
> > > 2. Is it still a good idea to have all of the operators in the same
> > > big file, or could I break them out into one file per operation (in
> > > a subdirectory most likely)?
> >
> > I'd like to keep small ones in one file, but larger ones could be
> > broken out.
> 
> Since there is the "short circuit" functionality of the `--commands'
> argument, it may make sense to have a small file with the information
> about the commands and then all of the code separate. Then again, since
> the amount of time it takes to parse some extra classes is probably
> pretty minimal, worrying too much about this is probably a waste of
> effort.

I don't think that's a waste of effort, this option is called by the shell to
ask for completion, so hitting <TAB> should answer pretty fast, and even with
my fast machine the difference is real.

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080617/997aa893/attachment.bin>

From wmorgan-ditz at masanjin.net  Tue Jun 17 16:33:34 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 17 Jun 2008 13:33:34 -0700
Subject: [ditz-talk] Operator Arguments
In-Reply-To: <1213729148-sup-908@ausone.local>
References: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
	<1213049896-sup-8944@entry>
	<ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>
	<1213729148-sup-908@ausone.local>
Message-ID: <1213734751-sup-450@entry>

Reformatted excerpts from nicolas.pouillard's message of 2008-06-17:
> I don't think that's a waste of effort, this option is called by the
> shell to ask for completion, so hitting <TAB> should answer pretty
> fast, and even with my fast machine the difference is real.

I think the three of us are in agreement---the current completion stuff
should stay as a short-circuit to be fast, but there's no
(speed-related) reason to move general operator stuff into a separate
file.
-- 
William <wmorgan-ditz at masanjin.net>

From nicolas.pouillard at gmail.com  Tue Jun 17 16:36:50 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Tue, 17 Jun 2008 22:36:50 +0200
Subject: [ditz-talk] Operator Arguments
In-Reply-To: <1213734751-sup-450@entry>
References: <ad21a5280806081936m715468afsb5d48b75a33a0ec9@mail.gmail.com>
	<1213049896-sup-8944@entry>
	<ad21a5280806161803w46078d28xe7f2f092e0a9347c@mail.gmail.com>
	<1213729148-sup-908@ausone.local> <1213734751-sup-450@entry>
Message-ID: <1213734995-sup-4961@ausone.local>

Excerpts from William Morgan's message of Tue Jun 17 22:33:34 +0200 2008:
> Reformatted excerpts from nicolas.pouillard's message of 2008-06-17:
> > I don't think that's a waste of effort, this option is called by the
> > shell to ask for completion, so hitting <TAB> should answer pretty
> > fast, and even with my fast machine the difference is real.
> 
> I think the three of us are in agreement---the current completion stuff
> should stay as a short-circuit to be fast, but there's no
> (speed-related) reason to move general operator stuff into a separate
> file.

Right.

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080617/a3721c83/attachment.bin>

From mail at exceptionfault.de  Wed Jun 18 09:31:10 2008
From: mail at exceptionfault.de (Andreas Habel)
Date: Wed, 18 Jun 2008 15:31:10 +0200
Subject: [ditz-talk] Problems with environment "HOME" under Windows
Message-ID: <20080618153110.tguax6cuwwc4ocsc@webmail.df.eu>

Hello William,

when I try to use ditz3.0 I receive the following error:

C:\>ditz --version
c:/ruby/lib/ruby/gems/1.8/gems/ditz-0.3/bin/ditz:34:in `join': can't  
convert nil into String (TypeError)
         from c:/ruby/lib/ruby/gems/1.8/gems/ditz-0.3/bin/ditz:34:in `cloaker_'
         from  
c:/ruby/lib/ruby/gems/1.8/gems/trollop-1.8/lib/trollop.rb:55:in `call'
         from  
c:/ruby/lib/ruby/gems/1.8/gems/trollop-1.8/lib/trollop.rb:55:in  
`initialize'
         from  
c:/ruby/lib/ruby/gems/1.8/gems/trollop-1.8/lib/trollop.rb:438:in `new'
         from  
c:/ruby/lib/ruby/gems/1.8/gems/trollop-1.8/lib/trollop.rb:438:in  
`options'
         from c:/ruby/lib/ruby/gems/1.8/gems/ditz-0.3/bin/ditz:31
         from c:/ruby/bin/ditz:16:in `load'
         from c:/ruby/bin/ditz:16

The mentioned line tries to get the value "HOME" from my environment,  
which is not set on my windows box.

>  opt :config_file, "Configuration file", :default =>  
> File.join(ENV["HOME"], CONFIG_FN)

Instead of "HOME" there are three other values defined:

HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\some-unc-path-to-my-home-share

If I do "C:\>set HOME=%HOMESHARE%", everything is fine...

C:\>ditz --version
ditz 0.3

I don't know, if HOMESHARE is the default for windows.

greetings
Andreas


From wmorgan-ditz at masanjin.net  Thu Jun 19 16:38:30 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 19 Jun 2008 13:38:30 -0700
Subject: [ditz-talk] Problems with environment "HOME" under Windows
In-Reply-To: <20080618153110.tguax6cuwwc4ocsc@webmail.df.eu>
References: <20080618153110.tguax6cuwwc4ocsc@webmail.df.eu>
Message-ID: <1213907856-sup-9522@entry>

Reformatted excerpts from Andreas Habel's message of 2008-06-18:
> Instead of "HOME" there are three other values defined:
> 
> HOMEDRIVE=H:
> HOMEPATH=\
> HOMESHARE=\\some-unc-path-to-my-home-share
> 
> If I do "C:\>set HOME=%HOMESHARE%", everything is fine...

Hm, looks like I am going to have to special-case this stuff for
Windows. Preliminary websearching suggests that HOMEDRIVE + HOMEPATH
is the thing to use.
-- 
William <wmorgan-ditz at masanjin.net>