0 false 2009-07-14T20:31:52-06:00 17257 213 help-for-common-errors 126089 9908 new 2009-07-14T20:31:57-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/213 At the topmost level of run, common errors need to be caught and help given to clarify what exactly is going on. Validation Errors ------------------------------ Example: @@@ ruby # Example::task class Example < Tap::Task config :a, 1, &c.integer end @@@ % rap example --a blue expected [Integer] but was: String This cannot be caught easily elsewhere. It's not a config parser issue, it happens afterwards during task initialization. You want to be able to see the full backtrace on debug. As a result, the best place to catch/override is right at the top. At the topmost level of run, common errors need to be caught and help given to clarify what exactly is going on. Validation Errors ------------------------------ Example: @@@ ruby # Example::task class Example < Tap::Task config :a, 1, &c.integer end @@@ % rap example --a blue expected [Integer] but was: String This cannot be caught easily elsewhere. It's not a config parser issue, it happens afterwards during task initialization. You want to be able to see the full backtrace on debug. As a result, the best place to catch/override is right at the top. <div><p>At the topmost level of run, common errors need to be caught and help given to clarify what exactly is going on.</p> <h2>Validation Errors</h2> <p>Example:</p> <pre><code class="ruby"> # Example::task class Example &lt; Tap::Task config :a, 1, &amp;c.integer end </code></pre> <pre> <code>% rap example --a blue expected [[Integer]](/projects/9908/changesets/Integer "Changeset 'Integer'") but was: String </code> </pre> <p>This cannot be caught easily elsewhere. It's not a config parser issue, it happens afterwards during task initialization. You want to be able to see the full backtrace on debug. As a result, the best place to catch/override is right at the top.</p></div> 0 false 2009-07-10T13:22:21-06:00 17257 212 make-default-shell-test-pattern 125546 9908 new 2009-07-10T13:22:29-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/212 That way you can take the standard tap notation directly. % tap ... Becomes tap and % ruby becomes ruby That way you can take the standard tap notation directly. % tap ... Becomes tap and % ruby becomes ruby <div><p>That way you can take the standard tap notation directly.</p> <pre> <code>% tap ... </code> </pre> <p>Becomes</p> <pre> <code>tap </code> </pre> <p>and</p> <pre> <code>% ruby </code> </pre> <p>becomes</p> <pre> <code>ruby </code> </pre></div> 1 false 2009-05-03T09:13:46-06:00 17257 206 schema-cleanup 104002 9908 new 2009-07-10T11:11:48-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/206 The build on schema can be cleaned up significantly. * consider extracting errors into a variable * methods to instantiate a node/join * long debug where the node/join metadata is printed In the future (possibly): * checking of join signatures The build on schema can be cleaned up significantly. * consider extracting errors into a variable * methods to instantiate a node/join * long debug where the node/join metadata is printed In the future (possibly): * checking of join signatures <div><p>The build on schema can be cleaned up significantly.</p> <ul> <li>consider extracting errors into a variable</li> <li>methods to instantiate a node/join</li> <li>long debug where the node/join metadata is printed</li> </ul> <p>In the future (possibly):</p> <ul> <li>checking of join signatures</li> </ul></div> 0 false 2009-07-09T12:08:26-06:00 17257 211 add-a-template-file-server-module 125369 9908 new 2009-07-09T12:08:31-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/211 This will be nice to add templated documentation to controllers. Example: nest :tutorial, Tap::Controller do def dispatch(route) if route == nil || route.empty? route = "index" end if path = module_path("#{route}.erb") render :file => path else raise ServerError.new("404 Error: page not found #{route}", 404) end end end This will be nice to add templated documentation to controllers. Example: nest :tutorial, Tap::Controller do def dispatch(route) if route == nil || route.empty? route = "index" end if path = module_path("#{route}.erb") render :file => path else raise ServerError.new("404 Error: page not found #{route}", 404) end end end <div><p>This will be nice to add templated documentation to controllers. Example:</p> <pre> <code> nest :tutorial, Tap::Controller do def dispatch(route) if route == nil || route.empty? route = "index" end if path = module_path("#{route}.erb") render :file =&gt; path else raise ServerError.new("404 Error: page not found #{route}", 404) end end end </code> </pre></div> 0 false 2009-03-22T09:47:16-06:00 17257 194 audit-cachestore-ie-replay-and-recovery 93249 9908 new 2009-06-01T12:14:50-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/194 Been considering how to do error recovery. Unwinding a workflow is now possible, in many cases, since Joins can store state as full-fledged objects (although if joins are blocks this isn't true... procs don't serialize). However, when you unwind a partially-run workflow you can lose information that is within some types of joins, like a theoretical counter, or in the current Join running in no-stack mode. Once you unwind back to app.run, you will have audits of all the results. That suggests a replay is possible but you need something that a given task can query for cached results. Then, in replay mode, you load a clean workflow, load the audits into the cache, and run the tasks so they use the cached results when possible. This should quickly re-create the state at the time of crash, without re-running upstream tasks. Notes: * Tasks cannot have side-effect in this case. Result is the only meaningful output of executing with inputs. * A clean, new workflow must be made. This allows joins to have 'side effects' like counters and such. Note after unwinding you will also have (via join.inputs/join.outputs) a full representation of the workflow, but this may be 'polluted' in the sense that there may be state changes. This is useful for inspection during debugging, and potentially for restart. For restart: * Joins would have to track their state explicitly, ie with @_results and @index so that a dump has a handle on results and where to restart. Been considering how to do error recovery. Unwinding a workflow is now possible, in many cases, since Joins can store state as full-fledged objects (although if joins are blocks this isn't true... procs don't serialize). However, when you unwind a partially-run workflow you can lose information that is within some types of joins, like a theoretical counter, or in the current Join running in no-stack mode. Once you unwind back to app.run, you will have audits of all the results. That suggests a replay is possible but you need something that a given task can query for cached results. Then, in replay mode, you load a clean workflow, load the audits into the cache, and run the tasks so they use the cached results when possible. This should quickly re-create the state at the time of crash, without re-running upstream tasks. Notes: * Tasks cannot have side-effect in this case. Result is the only meaningful output of executing with inputs. * A clean, new workflow must be made. This allows joins to have 'side effects' like counters and such. Note after unwinding you will also have (via join.inputs/join.outputs) a full representation of the workflow, but this may be 'polluted' in the sense that there may be state changes. This is useful for inspection during debugging, and potentially for restart. For restart: * Joins would have to track their state explicitly, ie with @_results and @index so that a dump has a handle on results and where to restart. <div><p>Been considering how to do error recovery. Unwinding a workflow is now possible, in many cases, since Joins can store state as full-fledged objects (although if joins are blocks this isn't true... procs don't serialize). However, when you unwind a partially-run workflow you can lose information that is within some types of joins, like a theoretical counter, or in the current Join running in no-stack mode.</p> <p>Once you unwind back to app.run, you will have audits of all the results. That suggests a replay is possible but you need something that a given task can query for cached results. Then, in replay mode, you load a clean workflow, load the audits into the cache, and run the tasks so they use the cached results when possible.</p> <p>This should quickly re-create the state at the time of crash, without re-running upstream tasks. Notes:</p> <ul> <li>Tasks cannot have side-effect in this case. Result is the only meaningful output of executing with inputs.</li> <li>A clean, new workflow must be made. This allows joins to have 'side effects' like counters and such.</li> </ul> <p>Note after unwinding you will also have (via join.inputs/join.outputs) a full representation of the workflow, but this may be 'polluted' in the sense that there may be state changes. This is useful for inspection during debugging, and potentially for restart.</p> <p>For restart:</p> <ul> <li>Joins would have to track their state explicitly, ie with @_results and @index so that a dump has a handle on results and where to restart.</li> </ul></div> 0 false 2009-05-25T12:33:11-06:00 17257 210 env-context-sharing 110790 9908 new 2009-05-25T12:33:15-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/210 In cases like this: @@@ ruby # add the tap env if necessary unless exe.any? {|env| env.root.root == TAP_HOME } exe.push Env.new(TAP_HOME, exe.context) end @@@ Really it's a shame exe.context needs to be provided beforehand. Perhaps a global context? Or perhaps merge contexts? In cases like this: @@@ ruby # add the tap env if necessary unless exe.any? {|env| env.root.root == TAP_HOME } exe.push Env.new(TAP_HOME, exe.context) end @@@ Really it's a shame exe.context needs to be provided beforehand. Perhaps a global context? Or perhaps merge contexts? <div><p>In cases like this:</p> <pre><code class="ruby"> # add the tap env if necessary unless exe.any? {|env| env.root.root == TAP_HOME } exe.push Env.new(TAP_HOME, exe.context) end </code></pre> <p>Really it's a shame exe.context needs to be provided beforehand. Perhaps a global context? Or perhaps merge contexts?</p></div> 17257 0 true 2008-08-06T10:11:57-06:00 17257 2008-10-22T00:00:00-06:00 10299 71 env 11951 9908 resolved bug tap 2009-05-25T12:32:08-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/71 Tap-1.0.0 Should Env perform some equality check based on Env#root.root? If two envs are somehow loaded in (ex when tap.yml for a gem sets root = "."), then this can cause a manifest error, and duplication. The current scheme searches for envs that are included in the flat_envs target... but at preset == must be checking object_id, and not just contents. Should Env perform some equality check based on Env#root.root? If two envs are somehow loaded in (ex when tap.yml for a gem sets root = "."), then this can cause a manifest error, and duplication. The current scheme searches for envs that are included in the flat_envs target... but at preset == must be checking object_id, and not just contents. <div><p> Should Env perform some equality check based on Env#root.root? If two envs are somehow loaded in (ex when tap.yml for a gem sets root = "."), then this can cause a manifest error, and duplication. </p><p> The current scheme searches for envs that are included in the flat_envs target... but at preset == must be checking object_id, and not just contents. </p></div> 0 true 2008-04-17T18:46:28-06:00 17257 2008-10-22T00:00:00-06:00 10299 5 config-editing 11915 9908 invalid feature tap 2009-05-25T12:31:10-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/5 Tap-1.0.0 Add the ability to load/change the tap.yml file configs, a-la git tap config gems blah blah blah tap config gems.add blah blah blah The notation uses .method to call a method on the configuration, where some sort of push or set is assumed. To print out the current setting: tap config gems Add the ability to load/change the tap.yml file configs, a-la git tap config gems blah blah blah tap config gems.add blah blah blah The notation uses .method to call a method on the configuration, where some sort of push or set is assumed. To print out the current setting: tap config gems <div><p> Add the ability to load/change the tap.yml file configs, a-la git </p><p> tap config gems blah blah blah </p><p> tap config gems.add blah blah blah </p><p> The notation uses .method to call a method on the configuration, where some sort of push or set is assumed. To print out the current setting: </p><p> tap config gems </p></div> 17257 0 true 2008-08-07T14:42:27-06:00 17257 2008-10-22T00:00:00-06:00 10299 73 console-requires 11930 9908 resolved feature tap 2009-05-25T12:30:10-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/73 Tap-1.0.0 Add some mechanism to easily find/require task files, especially the tapfile.rb files. Add some mechanism to easily find/require task files, especially the tapfile.rb files. <div><p>Add some mechanism to easily find/require task files, especially the tapfile.rb files.</p></div> 17257 0 true 2008-08-11T19:27:31-06:00 17257 2008-10-22T00:00:00-06:00 10299 81 check-tap-yml-gem-configurations-on-gem 11938 9908 invalid fix tap 2009-05-25T12:28:31-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/81 Tap-1.0.0 A configuration error results when a gem is installed with a tap.yml that specifies uninstalled gems. Obviously the best solution is to make the installed gem specify the other gems as dependencies. Add a rake task to execute before :gem to check: @@@ ruby task :check_tap_configuration do if File.exists?("tap.yml") require 'yaml' if (hash = YAML.load_file("tap.yml")).kind_of?(Hash) gemspec.dependencies.collect {|d| d.name } ... end end end task :gem => [:check_tap_configuration] @@@ A configuration error results when a gem is installed with a tap.yml that specifies uninstalled gems. Obviously the best solution is to make the installed gem specify the other gems as dependencies. Add a rake task to execute before :gem to check: @@@ ruby task :check_tap_configuration do if File.exists?("tap.yml") require 'yaml' if (hash = YAML.load_file("tap.yml")).kind_of?(Hash) gemspec.dependencies.collect {|d| d.name } ... end end end task :gem => [:check_tap_configuration] @@@ <div><p>A configuration error results when a gem is installed with a tap.yml that specifies uninstalled gems. Obviously the best solution is to make the installed gem specify the other gems as dependencies. Add a rake task to execute before :gem to check:</p> <pre><code class="ruby"> task :check_tap_configuration do if File.exists?(&quot;tap.yml&quot;) require 'yaml' if (hash = YAML.load_file(&quot;tap.yml&quot;)).kind_of?(Hash) gemspec.dependencies.collect {|d| d.name } ... end end end task :gem =&gt; [:check_tap_configuration] </code></pre></div> 17257 0 true 2008-09-10T10:16:31-06:00 17257 2008-10-22T00:00:00-06:00 10299 104 test-cmdline-workflows-that-use-tasks-from-multiple-gems 11953 9908 resolved tap testing 2009-05-25T12:24:15-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/104 Tap-1.0.0 Naturally, multiple gem versions will not work (or SHOULD NOT at any rate) but tasks from multiple gems should be used with ease. Naturally, multiple gem versions will not work (or SHOULD NOT at any rate) but tasks from multiple gems should be used with ease. <div><p>Naturally, multiple gem versions will not work (or SHOULD NOT at any rate) but tasks from multiple gems should be used with ease.</p></div> 17257 0 true 2008-12-31T11:00:45-07:00 17257 135 add-switch-turning-off-automatic-inference-of-config_file 52200 9908 invalid 2009-05-25T12:22:56-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/135 In Task.parse @@@ ruby # load configurations if app.inference config_path ||= app.filepath('config', "#{name}.yml") end @@@ In Task.parse @@@ ruby # load configurations if app.inference config_path ||= app.filepath('config', "#{name}.yml") end @@@ <div><p>In Task.parse</p> <pre><code class="ruby"> # load configurations if app.inference config_path ||= app.filepath('config', &quot;#{name}.yml&quot;) end </code></pre></div> 17257 0 true 2009-02-11T17:14:18-07:00 17257 150 appcontrollerrunstopterminate-activate-on-get 70298 9908 resolved server 2009-05-25T12:21:32-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/150 These calls modify the state of the server and should be post-only. Does there need to be a way to terminate an app with a get request? These calls modify the state of the server and should be post-only. Does there need to be a way to terminate an app with a get request? <div><p>These calls modify the state of the server and should be post-only. Does there need to be a way to terminate an app with a get request?</p></div> 17257 0 true 2009-02-11T17:09:35-07:00 17257 149 schemacontrollerrun-threading-model-is-brittle 70293 9908 invalid server 2009-05-25T12:21:06-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/149 As written, it suffers the following: * no assurance rounds will be enqued and executed one after the other * rounds from other threads may be interleaved * no assurance the queue is empty when a new round is added * suffers from the same stop/start flub as Exe http://bahuvrihi.lighthouseapp.com/projects/9908-tap-task-application/tickets/148-exerun-flubs-stopterminate (at least) As written, it suffers the following: * no assurance rounds will be enqued and executed one after the other * rounds from other threads may be interleaved * no assurance the queue is empty when a new round is added * suffers from the same stop/start flub as Exe http://bahuvrihi.lighthouseapp.com/projects/9908-tap-task-application/tickets/148-exerun-flubs-stopterminate (at least) <div><p>As written, it suffers the following:</p> <ul> <li>no assurance rounds will be enqued and executed one after the other</li> <li>rounds from other threads may be interleaved</li> <li>no assurance the queue is empty when a new round is added</li> <li>suffers from the same stop/start flub as Exe <a href="http://bahuvrihi.lighthouseapp.com/projects/9908-tap-task-application/tickets/148-exerun-flubs-stopterminate"> http://bahuvrihi.lighthouseapp.c...</a></li> </ul> <p>(at least)</p></div> 17257 0 true 2009-02-18T08:06:21-07:00 17257 171 extload-task 72563 9908 invalid tap-tasks 2009-05-25T12:20:15-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/171 Tap-Tasks should have an ExtLoad baseclass for loading using External. Dumps naturally become ExternalArchives. Tap-Tasks should have an ExtLoad baseclass for loading using External. Dumps naturally become ExternalArchives. <div><p>Tap-Tasks should have an ExtLoad baseclass for loading using External. Dumps naturally become ExternalArchives.</p></div> 0 true 2009-04-03T11:49:58-06:00 17257 201 app-needs-to-own-tasks 97118 9908 invalid threading 2009-05-25T12:19:16-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/201 Tasks refer back to an app, but to for easier thread safety, tasks need to only execute on a singly thread at a given time. Model. Within a workflow: ### nothing touches a task outside of process ## No looking up tasks that aren't defined for an instance and messing with them. In short stay away from the app queue, dependencies, etc. ### apps only execute a task on a single thread ### While in process, an app owns the task. Outside of process, set the app to nil. Together this means that while an app owns the task, the task may change. When an app doesn't own the task, the task will not change. This prevents synchronization to be implemented per task. But it also prevents thread-safe tasks from running in multiple places... Not a solution. What brings this up is workflows that my have to coordinate the inputs/configs for a particular task, for example tasks that use an io config for input/output. Maybe the problem is simply that mutable configs are getting used. Tasks refer back to an app, but to for easier thread safety, tasks need to only execute on a singly thread at a given time. Model. Within a workflow: ### nothing touches a task outside of process ## No looking up tasks that aren't defined for an instance and messing with them. In short stay away from the app queue, dependencies, etc. ### apps only execute a task on a single thread ### While in process, an app owns the task. Outside of process, set the app to nil. Together this means that while an app owns the task, the task may change. When an app doesn't own the task, the task will not change. This prevents synchronization to be implemented per task. But it also prevents thread-safe tasks from running in multiple places... Not a solution. What brings this up is workflows that my have to coordinate the inputs/configs for a particular task, for example tasks that use an io config for input/output. Maybe the problem is simply that mutable configs are getting used. <div><p>Tasks refer back to an app, but to for easier thread safety, tasks need to only execute on a singly thread at a given time.</p> <p>Model. Within a workflow:</p> <h3>nothing touches a task outside of process</h3> <p>No looking up tasks that aren't defined for an instance and messing with them. In short stay away from the app queue, dependencies, etc.<br></p> <h3>apps only execute a task on a single thread</h3> <p>While in process, an app owns the task. Outside of process, set the app to nil.</p> <p>Together this means that while an app owns the task, the task may change. When an app doesn't own the task, the task will not change. This prevents synchronization to be implemented per task.<br></p> <p>But it also prevents thread-safe tasks from running in multiple places... Not a solution.</p> <p>What brings this up is workflows that my have to coordinate the inputs/configs for a particular task, for example tasks that use an io config for input/output. Maybe the problem is simply that mutable configs are getting used.</p></div> 17257 0 true 2009-03-08T09:54:24-06:00 17257 184 controller-shortcut-to-find-minipath-for-self 89742 9908 resolved server 2009-05-25T12:18:03-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/184 That way it will be easier and more robust to write links to oneself: @@@ html <a href="tap-ubiquity%3Atap%2Fubiquity%2Fserver/shutdown"></a> @@@ That way it will be easier and more robust to write links to oneself: @@@ html <a href="tap-ubiquity%3Atap%2Fubiquity%2Fserver/shutdown"></a> @@@ <div><p>That way it will be easier and more robust to write links to oneself:</p> <pre><code class="html"> &lt;a href=&quot;tap-ubiquity%3Atap%2Fubiquity%2Fserver/shutdown&quot;&gt;&lt;/a&gt; </code></pre></div> 17257 0 true 2009-02-12T08:28:59-07:00 17257 152 tap-server-threading 70433 9908 invalid threading 2009-05-25T12:16:40-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/152 The server ideally will accept requests, return quickly, and then do work. To do so requires some sort of threading... but of course it's hard to guarantee all tasks may be threaded. I propose a three-mode model: * blocking - Each app runs on main thread preventing return of current request and handling of new requests * threaded - Only one app may execute on one execution thread at a time. All other apps block until the current app is done. This could be implemented with a queue so that a request may return and the app will wait it's turn to produce results. * multi-threaded - Each app runs on it's own thread. # blocking # No attention to threading required. # threaded # Threading requires each app is self-contained: all objects used by the app are it's own (queue, tasks, dependencies, etc). This is almost the case, although there are some outlying (bugs)[http://bahuvrihi.lighthouseapp.com/projects/9908-tap-task-application/tickets?q=tagged%3A%22threading%22]. Threading is less save than blocking but should not be dangerous provided no apps run off-queue. Effectively there are only two threads: * The server thread which utilizes env, interacts with the user, but does not work with apps or tasks (this could be an issue with globals). * The application thread which runs apps, but does not interact with the user or utilize env. # multithreaded # Multithreading also requires each app is self-contained. The server ideally will accept requests, return quickly, and then do work. To do so requires some sort of threading... but of course it's hard to guarantee all tasks may be threaded. I propose a three-mode model: * blocking - Each app runs on main thread preventing return of current request and handling of new requests * threaded - Only one app may execute on one execution thread at a time. All other apps block until the current app is done. This could be implemented with a queue so that a request may return and the app will wait it's turn to produce results. * multi-threaded - Each app runs on it's own thread. # blocking # No attention to threading required. # threaded # Threading requires each app is self-contained: all objects used by the app are it's own (queue, tasks, dependencies, etc). This is almost the case, although there are some outlying (bugs)[http://bahuvrihi.lighthouseapp.com/projects/9908-tap-task-application/tickets?q=tagged%3A%22threading%22]. Threading is less save than blocking but should not be dangerous provided no apps run off-queue. Effectively there are only two threads: * The server thread which utilizes env, interacts with the user, but does not work with apps or tasks (this could be an issue with globals). * The application thread which runs apps, but does not interact with the user or utilize env. # multithreaded # Multithreading also requires each app is self-contained. <div><p>The server ideally will accept requests, return quickly, and then do work. To do so requires some sort of threading... but of course it's hard to guarantee all tasks may be threaded. I propose a three-mode model:</p> <ul> <li>blocking - Each app runs on main thread preventing return of current request and handling of new requests</li> <li>threaded - Only one app may execute on one execution thread at a time. All other apps block until the current app is done. This could be implemented with a queue so that a request may return and the app will wait it's turn to produce results.</li> <li>multi-threaded - Each app runs on it's own thread.</li> </ul> <h1>blocking</h1> <p>No attention to threading required.</p> <h1>threaded</h1> <p>Threading requires each app is self-contained: all objects used by the app are it's own (queue, tasks, dependencies, etc). This is almost the case, although there are some outlying (bugs)[<a href="http://bahuvrihi.lighthouseapp.com/projects/9908-tap-task-application/tickets?q=tagged%3A%22threading%22">http://bahuvrihi.lighthouseapp.c...</a>].</p> <p>Threading is less save than blocking but should not be dangerous provided no apps run off-queue. Effectively there are only two threads:</p> <ul> <li>The server thread which utilizes env, interacts with the user, but does not work with apps or tasks (this could be an issue with globals).</li> <li>The application thread which runs apps, but does not interact with the user or utilize env.</li> </ul> <h1>multithreaded</h1> <p>Multithreading also requires each app is self-contained.</p></div> 0 false 2009-02-18T08:05:29-07:00 17257 170 ruby-options-for-raptap 72272 9908 new 2009-05-25T12:15:09-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/170 It would be nice if various ruby options (esp -I) were available from the command line. Equally useful, and a viable alternative, would be env configurations. It would be nice if various ruby options (esp -I) were available from the command line. Equally useful, and a viable alternative, would be env configurations. <div><p>It would be nice if various ruby options (esp -I) were available from the command line. Equally useful, and a viable alternative, would be env configurations.</p></div> 17257 0 true 2009-01-25T18:06:32-07:00 17257 140 executablequeue-rounds 63689 9908 invalid 2009-05-25T12:12:43-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/140 ExecutableQueue should be able to store rounds that effectively get appended when the current round expires. This will more closely emulate schema and solve some problems in Server. ExecutableQueue should be able to store rounds that effectively get appended when the current round expires. This will more closely emulate schema and solve some problems in Server. <div><p>ExecutableQueue should be able to store rounds that effectively get appended when the current round expires. This will more closely emulate schema and solve some problems in Server.</p></div> 17257 0 true 2009-02-21T23:14:11-07:00 17257 175 revisit-aggregate-join-logic 80615 9908 invalid 2009-05-25T12:10:30-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/175 Not efficient or useful for any other purpose. @@@ ruby #-- # TODO -- consider is there a better way to optimize this? # currently this method is only used by an aggregate join def has?(entry) # :nodoc: synchronize do entry_id = entry.object_id @rounds.each do |round| round.each do |enqued_entry| return true if entry_id == enqued_entry.object_id end end false end end @@@ Not efficient or useful for any other purpose. @@@ ruby #-- # TODO -- consider is there a better way to optimize this? # currently this method is only used by an aggregate join def has?(entry) # :nodoc: synchronize do entry_id = entry.object_id @rounds.each do |round| round.each do |enqued_entry| return true if entry_id == enqued_entry.object_id end end false end end @@@ <div><p>Not efficient or useful for any other purpose.</p> <pre><code class="ruby"> #-- # TODO -- consider is there a better way to optimize this? # currently this method is only used by an aggregate join def has?(entry) # :nodoc: synchronize do entry_id = entry.object_id @rounds.each do |round| round.each do |enqued_entry| return true if entry_id == enqued_entry.object_id end end false end end </code></pre></div> 17257 0 true 2009-03-01T08:05:38-07:00 17257 178 add-collect-option-on-join 87673 9908 invalid 2009-05-25T12:09:09-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/178 Collect would do the same thing as aggregate, but enque the task to the current round. Collect would do the same thing as aggregate, but enque the task to the current round. <div><p>Collect would do the same thing as aggregate, but enque the task to the current round.</p></div> 17257 0 true 2009-03-02T16:39:36-07:00 17257 180 argv-to-workflow-in-run 88097 9908 invalid 2009-05-25T12:07:30-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/180 Static workflows are great, but they need a way to receive arguments. One option is to hack into the schema, only allow one file in run and then tack on the args: @@@ text % tap run workflow.yml a b c @@@ Another option is to implement a workflow task: @@@ text % tap run -- workflow workflow.yml a b c @@@ (wap?) Which then makes a pass-through workflow and enques the inputs to node 0, and completes to the result of node -1. The workflow task would be a baseclass for more complicated pass-through workflows. You could make a generator that takes a workflow.yml as an input and builds a stub workflow task! Static workflows are great, but they need a way to receive arguments. One option is to hack into the schema, only allow one file in run and then tack on the args: @@@ text % tap run workflow.yml a b c @@@ Another option is to implement a workflow task: @@@ text % tap run -- workflow workflow.yml a b c @@@ (wap?) Which then makes a pass-through workflow and enques the inputs to node 0, and completes to the result of node -1. The workflow task would be a baseclass for more complicated pass-through workflows. You could make a generator that takes a workflow.yml as an input and builds a stub workflow task! <div><p>Static workflows are great, but they need a way to receive arguments. One option is to hack into the schema, only allow one file in run and then tack on the args:</p> <pre><code class="text"> % tap run workflow.yml a b c </code></pre> <p>Another option is to implement a workflow task:</p> <pre><code class="text"> % tap run -- workflow workflow.yml a b c </code></pre> <p>(wap?) Which then makes a pass-through workflow and enques the inputs to node 0, and completes to the result of node -1. The workflow task would be a baseclass for more complicated pass-through workflows. You could make a generator that takes a workflow.yml as an input and builds a stub workflow task!</p></div> 0 false 2009-03-16T10:33:25-06:00 17257 191 env-aggregate 91713 9908 new 2009-05-25T12:06:34-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/191 Envs make it seem like the files of nested environments are all in the same directory. Why not make a method that actually collects the nested environments into one place. This would facilitate freezing a development structure, and a variety of distribution models. Envs make it seem like the files of nested environments are all in the same directory. Why not make a method that actually collects the nested environments into one place. This would facilitate freezing a development structure, and a variety of distribution models. <div><p>Envs make it seem like the files of nested environments are all in the same directory. Why not make a method that actually collects the nested environments into one place. This would facilitate freezing a development structure, and a variety of distribution models.</p></div> 0 true 2009-02-16T08:35:52-07:00 17257 160 server-routing 70847 9908 invalid server 2009-05-25T11:58:14-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/160 Routing currently does something like: @@@ text /:controller(_controller)/:action @@@ Update this to: @@@ text /:controller_key/:action @@@ Such that using escapes you can specify a minikey for any constant. @@@ text /app/:action # => App /tap-server%3aapp/:action # => [tap-server] App /tap-server%3apath%2Fto%2Fapp/:action # => [tap-server] Path::To::App @@@ In this case env.controllers can become a 'standard' manifest and controllers can be put anywhere and marked by a '::controller' const_attr. What's more this makes view paths simpler with a single rule: 'views/path/to/const' Routing currently does something like: @@@ text /:controller(_controller)/:action @@@ Update this to: @@@ text /:controller_key/:action @@@ Such that using escapes you can specify a minikey for any constant. @@@ text /app/:action # => App /tap-server%3aapp/:action # => [tap-server] App /tap-server%3apath%2Fto%2Fapp/:action # => [tap-server] Path::To::App @@@ In this case env.controllers can become a 'standard' manifest and controllers can be put anywhere and marked by a '::controller' const_attr. What's more this makes view paths simpler with a single rule: 'views/path/to/const' <div><p>Routing currently does something like:</p> <pre><code class="text"> /:controller(_controller)/:action </code></pre> <p>Update this to:</p> <pre><code class="text"> /:controller_key/:action </code></pre> <p>Such that using escapes you can specify a minikey for any constant.</p> <pre><code class="text"> /app/:action # =&gt; App /tap-server%3aapp/:action # =&gt; [tap-server] App /tap-server%3apath%2Fto%2Fapp/:action # =&gt; [tap-server] Path::To::App </code></pre> <p>In this case env.controllers can become a 'standard' manifest and controllers can be put anywhere and marked by a '::controller' const_attr. What's more this makes view paths simpler with a single rule: 'views/path/to/const'</p></div> 0 false 2009-05-23T09:19:04-06:00 17257 209 indifferent-access-in-env-config 110491 9908 new 2009-05-23T09:19:09-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/209 Certain parts of env configuration is currently tied to symbols or strings. (strings for tap.yml files, for example). This should have indifferent access, in from_gemspec @@@ ruby config = { 'root' => path, 'gems' => dependencies, 'load_paths' => spec.require_paths, 'set_load_paths' => false } @@@ Certain parts of env configuration is currently tied to symbols or strings. (strings for tap.yml files, for example). This should have indifferent access, in from_gemspec @@@ ruby config = { 'root' => path, 'gems' => dependencies, 'load_paths' => spec.require_paths, 'set_load_paths' => false } @@@ <div><p>Certain parts of env configuration is currently tied to symbols or strings. (strings for tap.yml files, for example).<br></p> <p>This should have indifferent access, in from_gemspec</p> <pre><code class="ruby"> config = { 'root' =&gt; path, 'gems' =&gt; dependencies, 'load_paths' =&gt; spec.require_paths, 'set_load_paths' =&gt; false } </code></pre></div> 0 false 2009-05-17T11:25:14-06:00 17257 208 help-registry 107479 9908 new 2009-05-17T11:25:16-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/208 Command line apps like tap could really benefit from a help registry so that certain errors can be supplemented with user help. @@@ ruby begin # ... rescue raise if $DEBUG puts $!.message # replace this with a help registry if $!.message == "no nodes specified" && !ARGV.empty? puts "(did you mean 'tap run -- #{ARGV.join(' ')}'?)" end exit(1) end exit(0) @@@ Command line apps like tap could really benefit from a help registry so that certain errors can be supplemented with user help. @@@ ruby begin # ... rescue raise if $DEBUG puts $!.message # replace this with a help registry if $!.message == "no nodes specified" && !ARGV.empty? puts "(did you mean 'tap run -- #{ARGV.join(' ')}'?)" end exit(1) end exit(0) @@@ <div><p>Command line apps like tap could really benefit from a help registry so that certain errors can be supplemented with user help.</p> <pre><code class="ruby"> begin # ... rescue raise if $DEBUG puts $!.message # replace this with a help registry if $!.message == &quot;no nodes specified&quot; &amp;&amp; !ARGV.empty? puts &quot;(did you mean 'tap run -- #{ARGV.join(' ')}'?)&quot; end exit(1) end exit(0) </code></pre></div> 0 false 2009-05-05T22:35:26-06:00 17257 207 show-inheritance-hierarchy-in-help 104706 9908 new 2009-05-05T22:35:31-06:00 17257 bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/207 17257 0 true 2009-03-31T14:19:23-06:00 17257 196 expand-root-generator-configs 96532 9908 resolved 2009-05-05T14:13:54-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/196 Root Generator could also specify things like: * name * email * rubyforge-project * etc The basic gemspec inputs. This could be especially helpful if there is a static, global config file as well. Root Generator could also specify things like: * name * email * rubyforge-project * etc The basic gemspec inputs. This could be especially helpful if there is a static, global config file as well. <div><p>Root Generator could also specify things like:</p> <ul> <li>name</li> <li>email</li> <li>rubyforge-project</li> <li>etc</li> </ul> <p>The basic gemspec inputs. This could be especially helpful if there is a static, global config file as well.</p></div> 17257 0 true 2009-03-24T13:27:26-06:00 17257 195 additional-root-generator-update 94436 9908 invalid 2009-05-05T13:56:17-06:00 17257 bahuvrihi bahuvrihi bahuvrihi http://bahuvrihi.lighthouseapp.com/projects/9908/tickets/195 Yuck: @@@ ruby s.rdoc_options.concat %W{--main README -S -N --title Batch-search-paper} @@@ Capitalize doesn't exactly work, does is? Yuck: @@@ ruby s.rdoc_options.concat %W{--main README -S -N --title Batch-search-paper} @@@ Capitalize doesn't exactly work, does is? <div><p>Yuck:</p> <pre><code class="ruby"> s.rdoc_options.concat %W{--main README -S -N --title Batch-search-paper} </code></pre> <p>Capitalize doesn't exactly work, does is?</p></div>