On Thu, Dec 16, 2010 at 7:19 AM, Jon Kruger <jon-6DeS6rdMO/***@public.gmane.org> wrote:
>
> On Dec 16, 2010 7:31 AM, "Matt Wynne" <matt-***@public.gmane.org> wrote:
>>
>>
>> On 14 Dec 2010, at 23:57, Jon Kruger wrote:
>>
>>> I'm willing to do some of the work if someone can point me in the right
>>> direction.
>>>
>>> Jon
>>
>> Good man! Which option would you prefer to work on?
>
> I can do the filter option... are there any examples of filters in cucumber
> now?
>
Look in Gherkin. There are a few layers in there, and I'm not sure
where exactly Matt was thinking to put the filter in, but if you poke
around you should see how Gherkin works by composing classes that
send, receive and transform streams of events. Any filter will do
something very similar. I imagine we'll also need to modify the lexer,
unless we want to go with the special table cell syntax Matt used as
an example. I'm partial to using the multiline description to store
stuff like this, at least at first. It's a low-cost way to play around
with extensions to the core language and imposes few burdens on other
users of the library.
Mike
> Jon
>
>>
>>
>>> On Dec 14, 2010 6:51 PM, "aslak hellesoy" <aslak.hellesoy-***@public.gmane.org>
>>> wrote:
>>> > On Tue, Dec 14, 2010 at 4:13 PM, Jon Kruger <google-6DeS6rdMO/***@public.gmane.org>
>>> > wrote:
>>> >> The stdin approach is technically possible, but it doesn't seem to be
>>> >> as user-friendly. I want my QA people to be able to write cucumber
>>> >> tests. I want my QA people to be able to look at a book on Cucumber
>>> >> and have it make sense to them. People like that wouldn't necessarily
>>> >> know how to pipe something to a command, or where to pull the CSV
>>> >> translator from github.
>>> >>
>>> >> To me, either the preprocessor directive or the filter idea are better
>>> >> because it encapsulates all of this inside of Cucumber/Gherkin so that
>>> >> users don't need to know about the implementation (or how to call
>>> >> it). It's really easy then for a user to read a book or a blog post
>>> >> and say, "Hey, I can put #include myfile.csv (or whatever syntax we
>>> >> end up with) in my feature file and it will create examples from my
>>> >> CSV file!" It requires us to put the CSV parsing inside Cucumber/
>>> >> Gherkin, but I think that's a good thing. I wouldn't think that that
>>> >> code would be that hard to write.
>>> >>
>>> >> I don't have a problem with also implementing the stdin approach
>>> >> because then it would let people theoretically parse a feature file
>>> >> and transform it in any way, but that's something different than what
>>> >> I'm asking for. But if we were to implement this in Cucumber/Gherkin
>>> >> for CSV, we're already most of the way to supporting pipe-delimited
>>> >> files, Excel files, and other kinds of files (if that's something
>>> >> people wanted down the road).
>>> >>
>>> >
>>> > You're bringing up some good points Jon.
>>> >
>>> > It looks like we have three directions that:
>>> >
>>> > a) Can be used to solve the same problem of sucking in external content
>>> > b) Can be implemented independently without affecting the other
>>> > c) All have their value
>>> >
>>> > I therefore propose we do them all. My suggestion:
>>> >
>>> > * stdin: Mike, do it
>>> > * include: Aslak, do it
>>> > * filter: Matt, Mike or someone else, do it
>>> >
>>> > Common for them all is that they require fairly little code, so I'm
>>> > not too worried about redundancy. I think they all have their own
>>> > merits.
>>> >
>>> > One problem we have to be aware of with all solutions is line numbers.
>>> > As you all know, Cucumber reports gherkin files and line numbers, and
>>> > they still need to be correct. It would be unacceptable if cucumber
>>> > starts reporting incorrect line numbers and/or incorrect files. For
>>> > example, if an error happens in a file that came from a CSV, then the
>>> > error should point to that file, and (ideally) the right line within
>>> > it.
>>> >
>>> > Aslak
>>> >
>>> >> Jon
>>> >>
>>> >> On Dec 14, 8:45 am, Matt Wynne <m...-***@public.gmane.org> wrote:
>>> >>> On 14 Dec 2010, at 13:31, Mike Sassak wrote:
>>> >>>
>>> >>> > On Tue, Dec 14, 2010 at 4:02 AM, Matt Wynne <m...-***@public.gmane.org>
>>> >>> > wrote:
>>> >>>
>>> >>> >> On 14 Dec 2010, at 06:10, Mike Sassak wrote:
>>> >>>
>>> >>> >>> On Mon, Dec 13, 2010 at 5:34 PM, aslak hellesoy
>>> >>> >>> <aslak.helle...-***@public.gmane.org> wrote:
>>> >>> >>>> On Mon, Dec 13, 2010 at 7:24 PM, Mike Sassak <msas...-***@public.gmane.orgm>
>>> >>> >>>> wrote:
>>> >>> >>>>> On Mon, Dec 13, 2010 at 12:51 PM, Aslak Hellesøy
>>> >>> >>>>> <aslak.helle...-***@public.gmane.org> wrote:
>>> >>>
>>> >>> >>>>>> On Dec 11, 2010, at 9:26 PM, Matt Wynne <m...-***@public.gmane.org>
>>> >>> >>>>>> wrote:
>>> >>>
>>> >>> >>>>>> Jon, Mike,
>>> >>> >>>>>> On 11 Dec 2010, at 20:42, Jon Kruger wrote:
>>> >>>
>>> >>> >>>>>> On Sat, Dec 11, 2010 at 9:02 AM, Mike Sassak
>>> >>> >>>>>> <msas...-***@public.gmane.org> wrote:
>>> >>>
>>> >>> >>>>>>> On Sat, Dec 11, 2010 at 3:02 AM, Matt Wynne
>>> >>> >>>>>>> <m...-***@public.gmane.org> wrote:
>>> >>>
>>> >>> >>>>>>>> On 11 Dec 2010, at 04:09, Jon Kruger wrote:
>>> >>>
>>> >>> >>>>>>>>> Is there a way to import the "Examples" section of a
>>> >>> >>>>>>>>> Scenario Outline
>>> >>> >>>>>>>>> from a CSV file? There are two reasons I want to do this:
>>> >>>
>>> >>> >>>>>>>>> 1) If I have a lot of data, it's messy if it's in the
>>> >>> >>>>>>>>> .feature file
>>> >>> >>>>>>>>> 2) If it's in CSV, I can give the CSV file to a business
>>> >>> >>>>>>>>> person and
>>> >>> >>>>>>>>> they can fill in values using Excel
>>> >>>
>>> >>> >>>>>>>>> If there isn't a way to do this, I'd be willing to take a
>>> >>> >>>>>>>>> stab at it
>>> >>> >>>>>>>>> if someone can point me in the right direction.
>>> >>>
>>> >>> >>>>>>>>> Jon
>>> >>>
>>> >>> >>>>>>>> This has come up more than once, and I think it would be a
>>> >>> >>>>>>>> sweet feature
>>> >>> >>>>>>>> in Cucumber. To implement it would involve making a change
>>> >>> >>>>>>>> to gherkin[1],
>>> >>> >>>>>>>> which is the library that parses your .feature files.
>>> >>> >>>>>>>> Gherkin uses Ragel[2]
>>> >>> >>>>>>>> to parse the files, so the change would be to alter this
>>> >>> >>>>>>>> ragel code:
>>> >>>
>>> >>>
>>> >>> >>>>>>>> >>>>>>>>https://github.com/aslakhellesoy/gherkin/blob/master/ragel/lexer_comm...
>>> >>>
>>> >>> >>>>>>>> So that it accepts either an inline table or a reference to
>>> >>> >>>>>>>> a CSV file
>>> >>> >>>>>>>> after the Examples: keyword.
>>> >>>
>>> >>> >>>>>>>> Hacking on gherkin isn't entirely straightforward (see the
>>> >>> >>>>>>>> readme), as
>>> >>> >>>>>>>> it produces three versions (pure Ruby, C and Java) across
>>> >>> >>>>>>>> all 40 spoken
>>> >>> >>>>>>>> languages, but if you jump on #cucumber we could give you a
>>> >>> >>>>>>>> hand getting up
>>> >>> >>>>>>>> and running.
>>> >>>
>>> >>> >>>>>>>> [1]https://github.com/aslakhellesoy/gherkin
>>> >>> >>>>>>>> [2]http://www.complang.org/ragel/
>>> >>>
>>> >>> >>>>>>> Whoah there! This doesn't need to be implemented in the
>>> >>> >>>>>>> Gherkin lexer.
>>> >>> >>>>>>> If you place a URL or some other kind of identifier in the
>>> >>> >>>>>>> name of the
>>> >>> >>>>>>> Examples section or in its description, Gherkin will gladly
>>> >>> >>>>>>> send that
>>> >>> >>>>>>> straight on to Cucumber, where it can be retrieved, parsed
>>> >>> >>>>>>> and
>>> >>> >>>>>>> inserted into the internal representation of the feature.
>>> >>>
>>> >>> >>>>>>> I spent some time myself on plugins for Cucumber that would
>>> >>> >>>>>>> allow
>>> >>> >>>>>>> something like this, but gave up after a time because 1) it
>>> >>> >>>>>>> was
>>> >>> >>>>>>> becoming very frustrating, and 2) realizing that having
>>> >>> >>>>>>> Cucumber read
>>> >>> >>>>>>> streams of Gherkin-formatted text from STDIN was a more
>>> >>> >>>>>>> elegant
>>> >>> >>>>>>> solution. I haven't had the time to implement #2, but I think
>>> >>> >>>>>>> it's a
>>> >>> >>>>>>> better way to do this sort of thing.
>>> >>>
>>> >>> >>>>>>> $0.02
>>> >>> >>>>>>> Mike
>>> >>> >>>>>>> Mike,
>>> >>>
>>> >>> >>>>>> I wouldn't have to change the lexer code if we wanted to do it
>>> >>> >>>>>> like this:
>>> >>> >>>>>> Examples: my_values.csv
>>> >>> >>>>>> ... but we would have to change it if we wanted to do
>>> >>> >>>>>> something like this:
>>> >>> >>>>>> Examples:
>>> >>> >>>>>> @file: my_values.csv
>>> >>> >>>>>> Also, I would rather bring in a CSV file because part of the
>>> >>> >>>>>> point of this
>>> >>> >>>>>> is that I want to give the CSV file to a non-technical person
>>> >>> >>>>>> who can edit
>>> >>> >>>>>> it in Excel and then I could have those values define what my
>>> >>> >>>>>> code is
>>> >>> >>>>>> supposed to do.
>>> >>> >>>>>> Matt,
>>> >>> >>>>>> Any preference on how the syntax should look?
>>> >>> >>>>>> Jon
>>> >>>
>>> >>> >>>>>> I personally think it would make sense to do this in Gherkin,
>>> >>> >>>>>> so that
>>> >>> >>>>>> Cucumber doesn't need to care - it just gets a table from
>>> >>> >>>>>> Gherkin the same
>>> >>> >>>>>> as it would if the table were specified in the feature file as
>>> >>> >>>>>> normal. But
>>> >>> >>>>>> I'd like to hear more about Mike's concerns. Mike - are you
>>> >>> >>>>>> worried it will
>>> >>> >>>>>> make Gherkin dirty? Don't you think we'll end up with more of
>>> >>> >>>>>> a hack in
>>> >>> >>>>>> Cucumber if we did it the other way?
>>> >>> >>>>>> If you feel confident, I'd just give it a crack, and we can
>>> >>> >>>>>> see how it
>>> >>> >>>>>> looks.
>>> >>> >>>>>> As far as syntax, I think what you've suggested above looks
>>> >>> >>>>>> fine. Bear in
>>> >>> >>>>>> mind that each keyword in gherkin has space for a multiline
>>> >>> >>>>>> description
>>> >>> >>>>>> after it, so you could have...
>>> >>> >>>>>> Examples: This is the example name
>>> >>> >>>>>> This is the example's description
>>> >>> >>>>>> and so it this
>>> >>> >>>>>> because it can span over multiple lines.
>>> >>> >>>>>> @file: my_values.csv
>>> >>>
>>> >>> >>>>>> Guys,
>>> >>> >>>>>> It would be far simpler to add a generic preprocessor
>>> >>> >>>>>> #include directive
>>> >>> >>>>>> don't you think? More versatile too.
>>> >>> >>>>>> #include file:foo.txt
>>> >>> >>>>>> #includehttp://foo/bar.txt
>>> >>> >>>>>> It would be substituted with the content behind the URL and it
>>> >>> >>>>>> would be done
>>> >>> >>>>>> prior to lexing. It could be done in either gherkin or
>>> >>> >>>>>> cucumber.
>>> >>>
>>> >>> >>>>> I thought of a pre-processor at first, but rejected the idea
>>> >>> >>>>> because
>>> >>> >>>>> unless we're including gherkin source (a silly idea, I think),
>>> >>> >>>>> this
>>> >>> >>>>> adds unnecessary translation and parsing steps to the process.
>>> >>> >>>>> The
>>> >>> >>>>> external data would need to be retrieved, parsed in its native
>>> >>> >>>>> format,
>>> >>> >>>>> converted into gherkin, then parsed by Gherkin and converted
>>> >>> >>>>> into a
>>> >>> >>>>> series of events.
>>> >>>
>>> >>> >>>> #include:
>>> >>>
>>> >>> >>>> 1) retrieve CSV
>>> >>> >>>> 2) parse CSV
>>> >>> >>>> 3) convert to gherkin
>>> >>> >>>> 4) parse gherkin
>>> >>> >>>> 5) emit gherkin events
>>> >>>
>>> >>> >>>> We'd have to do 1-3. 4-5 is already implemented.
>>> >>>
>>> >>> >>>>> The filter way allows you to synthesize gherkin
>>> >>> >>>>> events from a native representation without needing to convert
>>> >>> >>>>> it to
>>> >>> >>>>> gherkin first.
>>> >>>
>>> >>> >>>> filters:
>>> >>>
>>> >>> >>>> 1) parse gherkin
>>> >>> >>>> 2) retrieve CSV
>>> >>> >>>> 3) parse CSV
>>> >>> >>>> 4) emit gherkin events
>>> >>>
>>> >>> >>>> We'd have to do 2-4
>>> >>>
>>> >>> >>>> Both approaches requires retrieving and parsing of CSV. They
>>> >>> >>>> differ by
>>> >>> >>>> whether we turn the parsed CSV into gherkin text or emit events.
>>> >>>
>>> >>> >>>> In terms of performance I suppose the #include approach would be
>>> >>> >>>> a
>>> >>> >>>> little slower than the filter approach. However, I don't think
>>> >>> >>>> the
>>> >>> >>>> overhead would be noticeable, so I don't think speed is a strong
>>> >>> >>>> argument here.
>>> >>>
>>> >>> >>>> I think it's more important to compare how easy it will be to
>>> >>> >>>> implement either architecture. We could implement a CSV to
>>> >>> >>>> gherkin
>>> >>> >>>> translator (as #source or as filter events) and bundle it with
>>> >>> >>>> gherkin
>>> >>> >>>> or cucumber. However, I'm sure some people would want to use
>>> >>> >>>> other
>>> >>> >>>> formats, such as Excel, Google Spreadsheets or some proprietary
>>> >>> >>>> Wiki.
>>> >>> >>>> That means they'll have to implement their own translator.
>>> >>>
>>> >>> >>>> Implementing a filter based translator requires knowledge of the
>>> >>> >>>> Gherkin API. Implementing an #include based translator only
>>> >>> >>>> requires
>>> >>> >>>> knowledge of the output gherkin.
>>> >>>
>>> >>> >>>> For this reason I'm leaning towards #include. It would also be
>>> >>> >>>> useable
>>> >>> >>>> anywhere in a gherkin file, not only for tables. Who knows,
>>> >>> >>>> maybe
>>> >>> >>>> somebody wants to suck in pystrings?
>>> >>>
>>> >>> >>>>>> Additionally an include directive could specify a translator
>>> >>> >>>>>> in case the URL
>>> >>> >>>>>> contains a MIME type that is not text/plain:
>>> >>> >>>>>> #include file:foo.xls, xls2txt
>>> >>> >>>>>> -where we could supply some simple converters ootb, and make
>>> >>> >>>>>> it easy for
>>> >>> >>>>>> people to write their own.
>>> >>>
>>> >>> >>>>> Why would we want to translate input for people? Seems easier
>>> >>> >>>>> to me to
>>> >>> >>>>> just say, "Hey, if you point us at crap, everything will fail.
>>> >>>
>>> >>> >>>> I can imagine some people might want to use google docs or
>>> >>> >>>> excel.
>>> >>>
>>> >>> >>>>> Don't
>>> >>> >>>>> point us at crap." The ability to insert a filter would
>>> >>> >>>>> side-step this
>>> >>> >>>>> nicely. Sounds to me like a job for the much talked about but
>>> >>> >>>>> never
>>> >>> >>>>> implemented stackable filters a la Rack API.
>>> >>>
>>> >>> >>>> The two approaches are not mutually exclusive - in theory we
>>> >>> >>>> could
>>> >>> >>>> support both. I just think #include is simpler in this case...
>>> >>>
>>> >>> >>> I agree they're not mutually exclusive, but I disagree about
>>> >>> >>> their
>>> >>> >>> relative complexity and usefulness. :-)
>>> >>>
>>> >>> >>> If you're leaning toward #include though, why not side-step a lot
>>> >>> >>> of
>>> >>> >>> the issues surrounding it (to start I think it's too hacky to be
>>> >>> >>> the
>>> >>> >>> official way of doing this) and add a --stdin flag to Cucumber?
>>> >>> >>> Right
>>> >>> >>> around the time I was getting really frustrated with the plugins
>>> >>> >>> I was
>>> >>> >>> lucky to have a chat with Dan North about what I was working on,
>>> >>> >>> and
>>> >>> >>> his suggestion was to forget about plugins entirely and just make
>>> >>> >>> it
>>> >>> >>> easy to pipe content into Cucumber like this:
>>> >>>
>>> >>> >>> $ wgethttp://example.com/feature.html| html2gherkin | cucumber
>>> >>> >>> --stdin
>>> >>>
>>> >>> >>> I thought this was such a good idea I wrote something to split
>>> >>> >>> apart
>>> >>> >>> features passed in via stdin and wired that up quick and dirty to
>>> >>> >>> a
>>> >>> >>> --stdin flag in Cucumber, and it worked pretty darn great for a
>>> >>> >>> night's work. Unfortunately I haven't had the time or inclination
>>> >>> >>> since then to finish the job. I still have the feature scanner
>>> >>> >>> here
>>> >>> >>> though:https://gist.github.com/460971. I'd do things a bit
>>> >>> >>> differently now, but the core packs a wallop in very few lines of
>>> >>> >>> code, in my opinion. This way we can easily let a thousand
>>> >>> >>> formats and
>>> >>> >>> converters bloom, and if any of them prove to be indispensable,
>>> >>> >>> we can
>>> >>> >>> fold the best stuff into Gherkin proper.
>>> >>>
>>> >>> >>> WDYT?
>>> >>> >>> Mike
>>> >>>
>>> >>> >> I think this sounds good in principle. Can you give me an example
>>> >>> >> of how the OP will use it to get his CSV file into the Examples table?
>>> >>>
>>> >>> > $ my-csv-expander | cucumber --stdin
>>> >>>
>>> >>> > my-csv-expander could easily read in the features according to what
>>> >>> > the OP would like and expand CSV references into Gherkin tables. To
>>> >>> > process a subset of features he could filter on a tag and have
>>> >>> > Cucumber run the others directly, or he could pass them through
>>> >>> > unchanged. There's not going to be much of a speed difference
>>> >>> > either
>>> >>> > way.
>>> >>>
>>> >>> I see. So my-csv-expander is a black box that reads the files in the
>>> >>> features directory, looks for some placeholder in the .feature files and
>>> >>> expands them into valid gherkin features, then spits them out of stdout?
>>> >>>
>>> >>> This would work nicely for supporting George's syntax, I guess.
>>> >>>
>>> >>> What does the OP think? Would you like this?
>>> >>>
>>> >>>
>>> >>>
>>> >>> > Best of all from my point of view is that we wouldn't need to
>>> >>> > decide
>>> >>> > on an official way to do this. If the OP wanted to publish
>>> >>> > my-csv-expander on Github and provide support for doing it his way,
>>> >>> > he
>>> >>> > could without having to listen to all those loud mouths on the
>>> >>> > Cucumber ML. ;-) If after a time my-csv-expander works so well
>>> >>> > everyone who Cukes uses it, we can include it or the best parts of
>>> >>> > it
>>> >>> > (and maybe include the best parts of some competing solutions) into
>>> >>> > Cucumber/Gherkin proper. Like Rails does with plugins and what-not.
>>> >>> > Named scope, nested attributes, and err... Merb were all developed
>>> >>> > elsewhere but proved they were so good they should take their place
>>> >>> > among the included batteries.
>>> >>>
>>> >>> > Gherkin then could have as one of its responsibilities making this
>>> >>> > type of thing easy (with filter composer and builder APIs), but if
>>> >>> > that never materializes, well so what? Munging streams of text by
>>> >>> > hand
>>> >>> > is definitely the Bell Labs solution, but there are advantages to
>>> >>> > it
>>> >>> > that MIT never dreamed of. I bet you could even do crazy stuff in
>>> >>> > Windows PowerShell with this approach. :-)
>>> >>>
>>> >>> > Mike
>>> >>>
>>> >>> >>>> Aslak
>>> >>>
>>> >>> >>>>> Mike
>>> >>>
>>> >>> >>>>>> Aslak
>>> >>>
>>> >>> >>>>>> cheers,
>>> >>> >>>>>> Matt
>>> >>> >>>>>> m...-***@public.gmane.org
>>> >>> >>>>>> 07974 430184
>>> >>>
>>> >>> >>>>>> --
>>> >>> >>>>>> You received this message because you are subscribed to the
>>> >>> >>>>>> Google Groups
>>> >>> >>>>>> "Cukes" group.
>>> >>> >>>>>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>>>> To unsubscribe from this group, send email to
>>> >>> >>>>>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>>>> For more options, visit this group at
>>> >>> >>>>>>http://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> >>>>>> --
>>> >>> >>>>>> You received this message because you are subscribed to the
>>> >>> >>>>>> Google Groups
>>> >>> >>>>>> "Cukes" group.
>>> >>> >>>>>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>>>> To unsubscribe from this group, send email to
>>> >>> >>>>>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>>>> For more options, visit this group at
>>> >>> >>>>>>http://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> >>>>> --
>>> >>> >>>>> You received this message because you are subscribed to the
>>> >>> >>>>> Google Groups "Cukes" group.
>>> >>> >>>>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>>> To unsubscribe from this group, send email to
>>> >>> >>>>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>>> For more options, visit this group
>>> >>> >>>>> athttp://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> >>>> --
>>> >>> >>>> You received this message because you are subscribed to the
>>> >>> >>>> Google Groups "Cukes" group.
>>> >>> >>>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>> To unsubscribe from this group, send email to
>>> >>> >>>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>>> For more options, visit this group
>>> >>> >>>> athttp://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> >>> --
>>> >>> >>> You received this message because you are subscribed to the
>>> >>> >>> Google Groups "Cukes" group.
>>> >>> >>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>> To unsubscribe from this group, send email to
>>> >>> >>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >>> For more options, visit this group
>>> >>> >>> athttp://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> >> cheers,
>>> >>> >> Matt
>>> >>>
>>> >>> >> m...-***@public.gmane.org
>>> >>> >> 07974 430184
>>> >>>
>>> >>> >> --
>>> >>> >> You received this message because you are subscribed to the Google
>>> >>> >> Groups "Cukes" group.
>>> >>> >> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >> To unsubscribe from this group, send email to
>>> >>> >> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> >> For more options, visit this group
>>> >>> >> athttp://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> > --
>>> >>> > You received this message because you are subscribed to the Google
>>> >>> > Groups "Cukes" group.
>>> >>> > To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> > To unsubscribe from this group, send email to
>>> >>> > cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >>> > For more options, visit this group
>>> >>> > athttp://groups.google.com/group/cukes?hl=en.
>>> >>>
>>> >>> cheers,
>>> >>> Matt
>>> >>>
>>> >>> m...-***@public.gmane.org
>>> >>> 07974 430184
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> >> Groups "Cukes" group.
>>> >> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >> To unsubscribe from this group, send email to
>>> >> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> >> For more options, visit this group at
>>> >> http://groups.google.com/group/cukes?hl=en.
>>> >>
>>> >>
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Cukes" group.
>>> > To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> > To unsubscribe from this group, send email to
>>> > cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/cukes?hl=en.
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Cukes" group.
>>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> To unsubscribe from this group, send email to
>>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> For more options, visit this group at
>>> http://groups.google.com/group/cukes?hl=en.
>>
>>
>> cheers,
>> Matt
>>
>> matt-***@public.gmane.org
>> 07974 430184
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Cukes" group.
>> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>> To unsubscribe from this group, send email to
>> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>> For more options, visit this group at
>> http://groups.google.com/group/cukes?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> To unsubscribe from this group, send email to
> cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/cukes?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.