Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-25 Thread Christian Egli 
John Hendy jw.he...@gmail.com writes:

 On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:

 You can already do so. IDs only have to be unique within the task
 siblings.

 True, one can name tasks identically as long as they have no identical
 siblings... but the point was the since one can only specify the
 lowest level of id (e.g. T1 instead of T.T1), Org doesn't know how
 to resolve them properly. 

AFAIK task_ids have to be globally unique if you want to use them for
dependencies.

 Task M1 ends up depending on both M.T1 (represented as !T1) /and/
 T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
 no way to set a depends option to target the specific T1 they wanted.
 Setting =:depends: !!T.T1= ignores the :depends: property entirely.

The TaskJuggler exporter gives you 3 ways to express a dependency:

1. using ORDERED on the parent task
2. using previous-sibling
3. using a task_id of another task. This has to be a unique id,
   otherwise you end up depending all the other tasks that have this
   task_id.

 You don't have to name parents either. You only need to name tasks that
 will be used as a dependency.

 True, which is nice. But we're torn between:
 - Letting Org name the parent whatever it wants, but then having to
 figure out the org-generated parent id so we can do =:depends:
 parent.subtask=, or

 - Specifically naming the parent to have control over the task_id, but
 having to change it because we move it later (and then updating all
 =:depends: parent.task_id= properties accordingly)

 And in either case, there's still no way to depend on a specific
 =parent.task_id= combination.

I don't understand this. Why do you need to name parents (or assign them
a task_id)? As Nicolas says: all you have to do is to give the task you
want to depend on a task_id. 

As an aside I thought you could also use plain ID to express
dependencies. But from looking at the code this doesn't seem supported.
I think the reason why yet another id (namely task_id) is used, is that
this allows for short human readable ids where as the standard ID is
generally generated by org mode and is cryptic and much longer.

HTH
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-24 Thread Christian Egli 
Buddy Butterfly buddy.butter...@web.de writes:


 The problem becomes obvious with your example above.
 Herr you expect that T8 would be unique across all
 tasks. If there are some other task paths with a task of
 T8 then this will not work. 

True, task_ids have to be unique across tasks. For me this was never a
problem as I usually do not have that many dependencies (and hence need
only a few task_ids) and org-mode has built in infrastructure to create
unique ids.

 You will always run after
 tj implementing what they have implemented. Why not
 write:

   :depends: !!T.T8

 directly? 

Because IMHO org-mode has more to offer in terms of dependencies. I
think that the ORDERED and the BLOCKER stuff gives you a good way to
model dependencies that is expressive and covers a lot of use cases
nicely. TaskJuggler dependencies is fairly low level I think. I'd like
to express my dependencies at a higher level. 

Hope that helps
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-24 Thread Christian Egli 
John Hendy jw.he...@gmail.com writes:

 Unique ids could be inserted as depends with some simple key strokes
 and I would't have to use numbered IDs at all. They'd stay with the
 tasks no matter where I moved them.

 For that... I'd actually prefer *not* to have to explicitly name the
 parent since they could move wherever I put them with no consequence.

`org-id-copy' will insert a unique ID into your entry (ie your task) and
at the same time store it in your kill ring, so you can then yank it
where you have the dependency. Can you try this with a custom key
binding? As far as I know the dependency resolution should also work
with unique id (aka ID) not just with task_ids.

HTH
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-04 Thread Buddy Butterfly 
Hi John,

regarding your potential IRC date with Christian Egli, I would like
to join, if I*ll find the time. For when is it scheduled? I have also posted
a base for discussion here on the list.

Thanks and best regards,
Matt



Am 01.04.2013 23:53, schrieb John Hendy:
 On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly buddy.butter...@web.de 
 wrote:
 Hi,

 regarding your example

   ** Milestones  :M:
   *** Task
   :PROPERTIES:
   :task_id: M2
   :depends: T8
   :END:

   ** Technical  :T:
  :PROPERTIES:
  :task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :task_id:  T8
   :duration: 1d
   :END:


 I would like to discus what I mean with a prefix.
 At the moment oex tries to mirror some functionality of
 tj to org mode. From an architectural point of view I
 would do this only for few selected functionalities.
 Otherwise you developers have to always adapt code to
 tj. If you would implement generic tj properties that
 will be exported as is, then one could easily write
 the tj stuff itself.

 The problem becomes obvious with your example above.
 Herr you expect that T8 would be unique across all
 tasks. If there are some other task paths with a task of
 T8 then this will not work. You will always run after
 tj implementing what they have implemented. Why not
 write:

   :depends: !!T.T8

 directly? This is what should be done. Leave the tj
 logic to tj and do not try to map it to org-mode.
 The more you map the more difficult to maintain, etc.

 I agree and would prefer this. Especially since folks wanting to
 export and being allowed to access tj functionality through drawers
 are probably going to anticipate using actual tj syntax in those
 drawers. Since tj only forces unique global ids (one can have M.T8,
 T.T8, etc.), this would solve the issue of ambiguity should one decide
 to use non-globally unique task ids. In fact, many projects may very
 well use a lot of repetitive tasks with the same properties.

 In mine, I have some tasks regarding shipping products to various
 countries. This way I could just have a bunch of country-specific
 headlines like:

 * Country
 ** Ship product

 * Country 2
 ** Ship product

 And could give all the ** Ship... tasks the same id since their
 Country parent would make it globally unique.

 For now, I'm just happy to have functionality restored so I can use
 Org and not hand-edit the files after exporting :) I have a potential
 IRC date with Christian Egli sometime this week... perhaps you should
 join and add your feedback? One of my other points of input would be
 that something like C-c l (Org store link at point) would be great.
 Unique ids could be inserted as depends with some simple key strokes
 and I would't have to use numbered IDs at all. They'd stay with the
 tasks no matter where I moved them.

 For that... I'd actually prefer *not* to have to explicitly name the
 parent since they could move wherever I put them with no consequence.


 John

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-01 Thread Buddy Butterfly 

Hi,

regarding your example

  ** Milestones  :M:
  *** Task
  :PROPERTIES:
  :task_id: M2
  :depends: T8
  :END:

  ** Technical  :T:
 :PROPERTIES:
 :task_id:  T
 :END:
  *** Task
  :PROPERTIES:
  :task_id:  T8
  :duration: 1d
  :END:


I would like to discus what I mean with a prefix.
At the moment oex tries to mirror some functionality of
tj to org mode. From an architectural point of view I
would do this only for few selected functionalities.
Otherwise you developers have to always adapt code to
tj. If you would implement generic tj properties that
will be exported as is, then one could easily write
the tj stuff itself.

The problem becomes obvious with your example above.
Herr you expect that T8 would be unique across all
tasks. If there are some other task paths with a task of
T8 then this will not work. You will always run after
tj implementing what they have implemented. Why not
write:

  :depends: !!T.T8

directly? This is what should be done. Leave the tj
logic to tj and do not try to map it to org-mode.
The more you map the more difficult to maintain, etc.

Also, you will likely only implement subsets of tj
properties.

For example, there are properties missing like

  :workinghours:

Lets look at an example. Suppose
we would prefix all taskjuggler properties with tj_
and org-mode would export tj_ properties as is.
People then would directly code the dependency
themself.

Your example would look like
(if directly replaced)

  ** Milestones  :M:
  *** Task
  :PROPERTIES:
  :tj_task_id: M2
  :tj_depends: !!T.T8
  :END:

  ** Technical  :T:
 :PROPERTIES:
 :tj_task_id:  T
 :END:
  *** Task
  :PROPERTIES:
  :tj_task_id:  T8
  :tj_duration: 1d
  :END:

Also, properties to the project tag should go into the
project task. With the functionality above, it would be easy to:

* Project  :taskjuggler_project:
  :workinhours: mon - fri 08:00 - 17:00

Or give a flag:


  ** Technical  :T:
 :PROPERTIES:
 :tj_task_id:  T
 :END:
  *** Task
  :PROPERTIES:
  :tj_task_id:  T8
  :tj_duration: 1d
  :tj_flag: tech8flag
  :END:


I have some other points to discuss. Will create a separate thread for it.

Cheers,
Matt



Am 01.04.2013 18:57, schrieb John Hendy:
 On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 John Hendy jw.he...@gmail.com writes:

 On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou n.goaz...@gmail.com 
 wrote:
 John Hendy jw.he...@gmail.com writes:

 I still have the issue of depending on a task not in the current
 subtree, but perhaps I'm just not using the exporter correctly:
 There was indeed a bug in the dependencies formatting. It should now be
 fixed in master. Could you confirm it?

 *** Task
 :PROPERTIES:
 :task_id:   M2
 :depends:  ??? what goes here to depend on T.T8 ???
 It should be :depends: T8

 Thank you for the feedback.

 That *would* work, but ox-taskjuggler has to correct for the fact that
 T8 does not live in M2's bucket (M). Using T8 gives me this:


 #+begin_src TJ
   task M2 Task {
 depends !T8
 milestone
   }
 #+end_src
 I cannot reproduce it. With:

 * Project  :taskjuggler_project:

   ** Milestones  :M:
   *** Task
   :PROPERTIES:
   :task_id: M2
   :depends: T8
   :END:

   ** Technical  :T:
  :PROPERTIES:
  :task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :task_id:  T8
   :duration: 1d
   :END:

 I get:

   task project Project {
 purge allocate
 allocate nicolas
 task milestones Milestones {
   task M2 Task {
 depends !!T.T8
 milestone
   }
 }
 task T Technical {
   task T8 Task {
 duration 1d
   }
 }
   }

 which looks correct. Did you reload Org properly after update?
 Process:
 - Save your patch to ~/Downloads/patch.patch
 - cd ~/.elisp/org.git
 - git branch tj-test
 - git checkout tj-test
 - patch -p1  ~/Downloads/patch.patch
 - make clean  make
 - start fresh Emacs session

 What perplexes me is that the id's mostly work (showing that the patch
 definitely changed from the master branch behavior), but not the same
 as you. With no task_id for Milestones, I'm getting:

 task nil Milestones {

 and you're getting

 task milestones Milestones {

 I'm also not getting the resolving of non-sibling depends attributes
 (getting just !T8 instead of !!T.T8).

 Did I not apply the patch or rebuild org properly? I'm pretty bad with
 git, and it surprises me that `git status` shows that ox-taskjuggler
 is modified when I switch back to master. I would have expected that
 my master branch would be oblivious to the changes I made on the
 tj-test branch (with `git branch tj-test  git checkout tj-test`).


 Thanks,
 John


 Regards,

 --
 Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-01 Thread Buddy Butterfly 
Correction, see below...

Am 01.04.2013 22:56, schrieb Buddy Butterfly:
 Hi,

 regarding your example

   ** Milestones  :M:
   *** Task
   :PROPERTIES:
   :task_id: M2
   :depends: T8
   :END:

   ** Technical  :T:
  :PROPERTIES:
  :task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :task_id:  T8
   :duration: 1d
   :END:


 I would like to discus what I mean with a prefix.
 At the moment oex tries to mirror some functionality of
 tj to org mode. From an architectural point of view I
 would do this only for few selected functionalities.
 Otherwise you developers have to always adapt code to
 tj. If you would implement generic tj properties that
 will be exported as is, then one could easily write
 the tj stuff itself.

 The problem becomes obvious with your example above.
 Herr you expect that T8 would be unique across all
 tasks. If there are some other task paths with a task of
 T8 then this will not work. You will always run after
 tj implementing what they have implemented. Why not
 write:

   :depends: !!T.T8

 directly? This is what should be done. Leave the tj
 logic to tj and do not try to map it to org-mode.
 The more you map the more difficult to maintain, etc.

 Also, you will likely only implement subsets of tj
 properties.

 For example, there are properties missing like

   :workinghours:

 Lets look at an example. Suppose
 we would prefix all taskjuggler properties with tj_
 and org-mode would export tj_ properties as is.
 People then would directly code the dependency
 themself.

 Your example would look like
 (if directly replaced)

   ** Milestones  :M:
   *** Task
   :PROPERTIES:
   :tj_task_id: M2
   :tj_depends: !!T.T8
   :END:

   ** Technical  :T:
  :PROPERTIES:
  :tj_task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :tj_task_id:  T8
   :tj_duration: 1d
   :END:

 Also, properties to the project tag should go into the
 project task. With the functionality above, it would be easy to:

 * Project  :taskjuggler_project:
   :tj_workinhours: mon - fri 08:00 - 17:00

 Or give a flag:


   ** Technical  :T:
  :PROPERTIES:
  :tj_task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :tj_task_id:  T8
   :tj_duration: 1d
   :tj_flag: tech8flag
   :END:


 I have some other points to discuss. Will create a separate thread for it.

 Cheers,
 Matt



 Am 01.04.2013 18:57, schrieb John Hendy:
 On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 John Hendy jw.he...@gmail.com writes:

 On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou n.goaz...@gmail.com 
 wrote:
 John Hendy jw.he...@gmail.com writes:

 I still have the issue of depending on a task not in the current
 subtree, but perhaps I'm just not using the exporter correctly:
 There was indeed a bug in the dependencies formatting. It should now be
 fixed in master. Could you confirm it?

 *** Task
 :PROPERTIES:
 :task_id:   M2
 :depends:  ??? what goes here to depend on T.T8 ???
 It should be :depends: T8

 Thank you for the feedback.

 That *would* work, but ox-taskjuggler has to correct for the fact that
 T8 does not live in M2's bucket (M). Using T8 gives me this:


 #+begin_src TJ
   task M2 Task {
 depends !T8
 milestone
   }
 #+end_src
 I cannot reproduce it. With:

 * Project  :taskjuggler_project:

   ** Milestones  :M:
   *** Task
   :PROPERTIES:
   :task_id: M2
   :depends: T8
   :END:

   ** Technical  :T:
  :PROPERTIES:
  :task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :task_id:  T8
   :duration: 1d
   :END:

 I get:

   task project Project {
 purge allocate
 allocate nicolas
 task milestones Milestones {
   task M2 Task {
 depends !!T.T8
 milestone
   }
 }
 task T Technical {
   task T8 Task {
 duration 1d
   }
 }
   }

 which looks correct. Did you reload Org properly after update?
 Process:
 - Save your patch to ~/Downloads/patch.patch
 - cd ~/.elisp/org.git
 - git branch tj-test
 - git checkout tj-test
 - patch -p1  ~/Downloads/patch.patch
 - make clean  make
 - start fresh Emacs session

 What perplexes me is that the id's mostly work (showing that the patch
 definitely changed from the master branch behavior), but not the same
 as you. With no task_id for Milestones, I'm getting:

 task nil Milestones {

 and you're getting

 task milestones Milestones {

 I'm also not getting the resolving of non-sibling depends attributes
 (getting just !T8 instead of !!T.T8).

 Did I not apply the patch or rebuild org properly? I'm pretty bad with
 git, and it surprises me that `git status` shows that ox-taskjuggler
 is modified when I switch back to master. I would have expected that
 my master branch would be oblivious to the changes I made on the
 tj-test branch (with `git branch tj-test  git checkout tj-test`).


 Thanks,
 John

 Regards,

 --
 Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-01 Thread John Hendy 
On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly buddy.butter...@web.de wrote:

 Hi,

 regarding your example

   ** Milestones  :M:
   *** Task
   :PROPERTIES:
   :task_id: M2
   :depends: T8
   :END:

   ** Technical  :T:
  :PROPERTIES:
  :task_id:  T
  :END:
   *** Task
   :PROPERTIES:
   :task_id:  T8
   :duration: 1d
   :END:


 I would like to discus what I mean with a prefix.
 At the moment oex tries to mirror some functionality of
 tj to org mode. From an architectural point of view I
 would do this only for few selected functionalities.
 Otherwise you developers have to always adapt code to
 tj. If you would implement generic tj properties that
 will be exported as is, then one could easily write
 the tj stuff itself.

 The problem becomes obvious with your example above.
 Herr you expect that T8 would be unique across all
 tasks. If there are some other task paths with a task of
 T8 then this will not work. You will always run after
 tj implementing what they have implemented. Why not
 write:

   :depends: !!T.T8

 directly? This is what should be done. Leave the tj
 logic to tj and do not try to map it to org-mode.
 The more you map the more difficult to maintain, etc.


I agree and would prefer this. Especially since folks wanting to
export and being allowed to access tj functionality through drawers
are probably going to anticipate using actual tj syntax in those
drawers. Since tj only forces unique global ids (one can have M.T8,
T.T8, etc.), this would solve the issue of ambiguity should one decide
to use non-globally unique task ids. In fact, many projects may very
well use a lot of repetitive tasks with the same properties.

In mine, I have some tasks regarding shipping products to various
countries. This way I could just have a bunch of country-specific
headlines like:

* Country
** Ship product

* Country 2
** Ship product

And could give all the ** Ship... tasks the same id since their
Country parent would make it globally unique.

For now, I'm just happy to have functionality restored so I can use
Org and not hand-edit the files after exporting :) I have a potential
IRC date with Christian Egli sometime this week... perhaps you should
join and add your feedback? One of my other points of input would be
that something like C-c l (Org store link at point) would be great.
Unique ids could be inserted as depends with some simple key strokes
and I would't have to use numbered IDs at all. They'd stay with the
tasks no matter where I moved them.

For that... I'd actually prefer *not* to have to explicitly name the
parent since they could move wherever I put them with no consequence.


John

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-01 Thread Nicolas Goaziou 
John Hendy jw.he...@gmail.com writes:

 I agree and would prefer this. Especially since folks wanting to
 export and being allowed to access tj functionality through drawers
 are probably going to anticipate using actual tj syntax in those
 drawers. Since tj only forces unique global ids (one can have M.T8,
 T.T8, etc.), this would solve the issue of ambiguity should one decide
 to use non-globally unique task ids. In fact, many projects may very
 well use a lot of repetitive tasks with the same properties.

 In mine, I have some tasks regarding shipping products to various
 countries. This way I could just have a bunch of country-specific
 headlines like:

 * Country
 ** Ship product

 * Country 2
 ** Ship product

 And could give all the ** Ship... tasks the same id since their
 Country parent would make it globally unique.

You can already do so. IDs only have to be unique within the task
siblings.

 For now, I'm just happy to have functionality restored so I can use
 Org and not hand-edit the files after exporting :) I have a potential
 IRC date with Christian Egli sometime this week... perhaps you should
 join and add your feedback? One of my other points of input would be
 that something like C-c l (Org store link at point) would be great.
 Unique ids could be inserted as depends with some simple key strokes
 and I would't have to use numbered IDs at all. They'd stay with the
 tasks no matter where I moved them.

 For that... I'd actually prefer *not* to have to explicitly name the
 parent since they could move wherever I put them with no consequence.

You don't have to name parents either. You only need to name tasks that
will be used as a dependency.


Regards,

-- 
Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export tj prefixing

2013-04-01 Thread John Hendy 
On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 John Hendy jw.he...@gmail.com writes:

 I agree and would prefer this. Especially since folks wanting to
 export and being allowed to access tj functionality through drawers
 are probably going to anticipate using actual tj syntax in those
 drawers. Since tj only forces unique global ids (one can have M.T8,
 T.T8, etc.), this would solve the issue of ambiguity should one decide
 to use non-globally unique task ids. In fact, many projects may very
 well use a lot of repetitive tasks with the same properties.

 In mine, I have some tasks regarding shipping products to various
 countries. This way I could just have a bunch of country-specific
 headlines like:

 * Country
 ** Ship product

 * Country 2
 ** Ship product

 And could give all the ** Ship... tasks the same id since their
 Country parent would make it globally unique.

 You can already do so. IDs only have to be unique within the task
 siblings.

True, one can name tasks identically as long as they have no identical
siblings... but the point was the since one can only specify the
lowest level of id (e.g. T1 instead of T.T1), Org doesn't know how
to resolve them properly. Consider this  modified test file:

#+begin_src org

* Project  :taskjuggler_project:

** Milestones  :M:
*** M.M1
  :PROPERTIES:
  :task_id: M1
  :depends: T1
  :END:
*** M.T1
:PROPERTIES:
:task_id:  T1
:END:
** Technical  :T:
 :PROPERTIES:
 :task_id:  T
 :END:
*** T.T1
   :PROPERTIES:
   :task_id:  T1
   :END:

#+end_src

The resultant TJ export:

#+begin_src tj

task milestones Milestones {
  purge allocate
  allocate jwhendy
  task M1 M.M1 {
depends !T1, !!T.T1
milestone
  }
  task T1 M.T1 {
milestone
  }
}
task T Technical {
  task T1 T.T1 {
milestone
  }
}

#+end_src

Task M1 ends up depending on both M.T1 (represented as !T1) /and/
T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
no way to set a depends option to target the specific T1 they wanted.
Setting =:depends: !!T.T1= ignores the :depends: property entirely.


Best regards,
John


 For now, I'm just happy to have functionality restored so I can use
 Org and not hand-edit the files after exporting :) I have a potential
 IRC date with Christian Egli sometime this week... perhaps you should
 join and add your feedback? One of my other points of input would be
 that something like C-c l (Org store link at point) would be great.
 Unique ids could be inserted as depends with some simple key strokes
 and I would't have to use numbered IDs at all. They'd stay with the
 tasks no matter where I moved them.

 For that... I'd actually prefer *not* to have to explicitly name the
 parent since they could move wherever I put them with no consequence.

 You don't have to name parents either. You only need to name tasks that
 will be used as a dependency.


True, which is nice. But we're torn between:
- Letting Org name the parent whatever it wants, but then having to
figure out the org-generated parent id so we can do =:depends:
parent.subtask=, or

- Specifically naming the parent to have control over the task_id, but
having to change it because we move it later (and then updating all
=:depends: parent.task_id= properties accordingly)

And in either case, there's still no way to depend on a specific
=parent.task_id= combination.


Best regards,
John


 Regards,

 --
 Nicolas Goaziou