{12} Report all tickets? (15 matches)

Id Type Time Changetime Component Severity Priority Owner Reporter Cc Version Milestone Status Resolution Summary Description Keywords
#442 enhancement 04:06:53 1264651613 Primitives None major blamario 0.4 0.5 new None Add more primitive producers

Add more non-IO primitive producers, such as:

  • infinite repeating producer,
  • natural number producer,
  • random number producer.
#443 enhancement 04:15:00 1264652100 Combinators None major blamario 0.4 0.5 new None Add zipping and merging components

A zip component would be similar to zip and zipWith functions on lists, except it would be working on two sources and sending results into a sink. It would have to stop when either of the sources is exhausted.

A merge component would also take two sources and one sink, but they'd all need to have the same type and it would run as long as either source provides more input.

It's not too clear what combinators could apply to these component types.

#444 defect 16:31:13 1266251473 Combinators None major blamario 0.4 new None The followedBy combinator needs to know about region ends

Tests occasionally fail because substring is not capable of telling followedBy where the end of the first of two overlapping strings is.

*Main> splitterOutputs (substring [Three,Three] followedBy substring [Three]) [Three,Three,Three] ([Three,Three],[Three])

#446 defect 03:07:57 1269228261 Monad.Coroutine None minor blamario 0.5 new None The merge function does not seem to run its argument coroutines in parallel

Function 

Control.Monad.Coroutine.merge :: forall s m x. (Monad m, Functor s) =>
                                 (forall x. [m x] -> m [x]) -> (forall x. [s x] -> s [x])
                              -> [Coroutine s m x] -> Coroutine s m [x]

appears to work properly, except that its test in the TestCoroutine? module apparently always uses only one CPU core.

#447 enhancement 03:42:47 1271904167 Primitives None major blamario 0.5 new None Add block-level IO

The fromHandle producer and toHandle consumer should be reading and writing whole blocks instead of individual characters. The easiest way to integrate them with the other components would be through combinators that convert block components to single-character components.

#448 enhancement 04:18:49 1271906329 Shell None major blamario 0.5 new None Try the finally tagless approach for shell

The shell type system should be embeddable using the finally tagless approach.

Also see http://lambda-the-ultimate.org/node/2438

#449 task 04:03:07 1284260587 Streams None major blamario 0.5 new None Try inverting the producer/consumer arguments to seesawNested in pipeG

The tests begin to fail. This is disturbing and should be investigated.

#450 task 20:07:41 1285441661 Combinators None minor blamario new None The substring and parseSubstring primitives could be made more bulky

The substring and parseSubstring primitives use the bulk operations pourUntil and getPrefixOf only for the top-level string. Then they switch to the old algorithm that checks for overlaps. This is a kludge, it must be possible to generalize the test definition.

#451 enhancement 03:16:52 1289531812 Combinators None major blamario 0.6 new None Add pattern-matching component type, its primitives and combinators

Splitters are not really the best choice for pattern-matching components. There should be a different component type for that purpose. It would still take one source and two sinks of the same type - one for the matching part of the input and the other for the consumed, but unmatched part - but it would not consume any input beyond what it needs to establish the match portion.

#452 enhancement 03:22:50 1289532170 Combinators None minor blamario new None Add support for time-tagged items

Streams allow more things to be done when each of them items carries a time stamp. A transducer of such streams can be made an arrow, for example.

#453 task 03:28:55 1289878135 Monad.Coroutine None major blamario 0.6 new None Add QuickCheck testsuite for monad-coroutine

The current test for monad-coroutine are not very thorough, and they are mostly good only for performance testing. A QuickCheck test suite is needed.

#454 defect 03:35:11 1289878511 Monad.Parallel None major blamario 0.6 new None Use Criterion for benchmarking

Add a Criterion benchmark suite for evaluating the speed of monad-parallel, monad-coroutine and SCC. The former two should be easy, because the existing tests are pretty much already used for benchmarking.

#445 defect 16:31:14 1268952384 Combinators None major blamario 0.4 closed duplicate The followedBy combinator needs to know about region ends

Tests occasionally fail because substring is not capable of telling followedBy where the end of the first of two overlapping strings is.

*Main> splitterOutputs (substring [Three,Three] followedBy substring [Three]) [Three,Three,Three] ([Three,Three],[Three])

#455 enhancement 04:47:39 1292387471 Monad.Coroutine None major None blamario 0.6 0.7 closed fixed Add a Functor instance for Coroutine s m
#456 enhancement 04:52:58 1292384744 Monad.Parallel None major blamario 0.5 0.7 closed fixed Add MonadParallel instances for other base library monads

ReadP and ReadPrec should be parallelizable, as well as ((->) r) and Either e.

Note: See TracReports for help on using and creating reports.