From blangner+ at cs.cmu.edu Thu May 1 12:22:51 2008 From: blangner+ at cs.cmu.edu (Brian Langner) Date: Thu, 01 May 2008 12:22:51 -0400 Subject: [Olympus developers 20]: [Fwd: binding filters] Message-ID: <4819EE5B.6010301@cs.cmu.edu> The group from Columbia that's building an Olympus system has a question regarding binding filters - can someone help answer? Brian > -------- Original Message -------- > Subject: binding filters > > > I'm still trying to understand how exactly do binding filters work > within the dialog manager. > The only example that I have is MeetingLine, and I see that it declares: > > USE_BINDING_FILTERS( > // the date-time binding filter > BINDING_FILTER("datetime", DateTimeBindingFilter) > ) > > however I don't quite understand where else in the code it is used. > My understanding is that the user in MeetingLine can only ask about > the last meeting or the previous meeting. There is no date or time > input by the user... so is the binding filter used? where? how? > > Do you have code examples that I can look at where the user is > actually speaking a date or number so I can see in the corresponding > request agent how that is handled and how the binding filter is > actually called? > > Is there any documentation on how BINDING_FILTER() works? > In the BindingFilters.cpp code there are comments referring to some > documentation, but in the version of MeetingLine we got from the > repository the Documentation folder in the solution is empty. Do you > have that file? Would that help and if so could you send it to me? > > From bfrisch at gmail.com Sat May 3 18:40:26 2008 From: bfrisch at gmail.com (Benjamin Frisch) Date: Sat, 3 May 2008 17:40:26 -0500 Subject: [Olympus developers 21]: Trac.speech's Trac will Be Disabled Message-ID: Trac.speech's trac will be disabled in about 15 minutes for an upgrade that is expected to last no more than another 15 minutes. There is also expected to a few second interruption in SVN support as the server is restarted. Thank you, Benjamin Frisch CMU Speech Lab Intern -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.srv.cs.cmu.edu/pipermail/olympus-developers/attachments/20080503/cd227058/attachment.html From bfrisch at cs.cmu.edu Sat May 3 19:23:46 2008 From: bfrisch at cs.cmu.edu (Benjamin Frisch) Date: Sat, 3 May 2008 18:23:46 -0500 Subject: [Olympus developers 22]: Re: Trac.speech's Trac will Be Disabled In-Reply-To: References: Message-ID: Upgrade is complete. You may resume using Trac.speech normally now. Ben Frusch On Sat, May 3, 2008 at 5:40 PM, Benjamin Frisch wrote: > Trac.speech's trac will be disabled in about 15 minutes for an upgrade that > is expected to last no more than another 15 minutes. There is also expected > to a few second interruption in SVN support as the server is restarted. > > Thank you, > Benjamin Frisch > CMU Speech Lab Intern > From blangner+ at cs.cmu.edu Sat May 3 20:13:05 2008 From: blangner+ at cs.cmu.edu (Brian Langner) Date: Sat, 03 May 2008 20:13:05 -0400 Subject: [Olympus developers 23]: Re: [Fwd: binding filters] In-Reply-To: <4819EE5B.6010301@cs.cmu.edu> References: <4819EE5B.6010301@cs.cmu.edu> Message-ID: <481CFF91.10009@cs.cmu.edu> Any answers, guys? I'd really rather not make these people wait more than a week for a reasonable answer from us... Brian Langner wrote: > The group from Columbia that's building an Olympus system has a question > regarding binding filters - can someone help answer? > > Brian > > >> -------- Original Message -------- >> Subject: binding filters >> >> >> I'm still trying to understand how exactly do binding filters work >> within the dialog manager. >> The only example that I have is MeetingLine, and I see that it declares: >> >> USE_BINDING_FILTERS( >> // the date-time binding filter >> BINDING_FILTER("datetime", DateTimeBindingFilter) >> ) >> >> however I don't quite understand where else in the code it is used. >> My understanding is that the user in MeetingLine can only ask about >> the last meeting or the previous meeting. There is no date or time >> input by the user... so is the binding filter used? where? how? >> >> Do you have code examples that I can look at where the user is >> actually speaking a date or number so I can see in the corresponding >> request agent how that is handled and how the binding filter is >> actually called? >> >> Is there any documentation on how BINDING_FILTER() works? >> In the BindingFilters.cpp code there are comments referring to some >> documentation, but in the version of MeetingLine we got from the >> repository the Documentation folder in the solution is empty. Do you >> have that file? Would that help and if so could you send it to me? >> >> > > > From tkharris at cs.cmu.edu Sat May 3 23:31:50 2008 From: tkharris at cs.cmu.edu (TK Harris) Date: Sat, 03 May 2008 23:31:50 -0400 Subject: [Olympus developers 24]: Re: [Fwd: binding filters] In-Reply-To: <481CFF91.10009@cs.cmu.edu> References: <4819EE5B.6010301@cs.cmu.edu> <481CFF91.10009@cs.cmu.edu> Message-ID: <481D2E26.4070000@cs.cmu.edu> So there is some DateTime documentation on the wiki. It was an orphaned page, as "Date Time". The list of components referred to "DateTime". I changed the page name to match what's in the component list, so you can now find it at: http://wiki.speech.cs.cmu.edu/olympus/index.php/DateTime There's also the following documentation on binding filters: http://wiki.speech.cs.cmu.edu/olympus/index.php/RavenClaw_Grammar_Mappings_and_Binding_Filters I just reworked that page so that it's a little easier to follow. -Thomas Brian Langner wrote: > Any answers, guys? I'd really rather not make these people wait more > than a week for a reasonable answer from us... > > Brian Langner wrote: >> The group from Columbia that's building an Olympus system has a >> question regarding binding filters - can someone help answer? >> >> Brian >> >> >>> -------- Original Message -------- >>> Subject: binding filters >>> >>> >>> I'm still trying to understand how exactly do binding filters work >>> within the dialog manager. >>> The only example that I have is MeetingLine, and I see that it >>> declares: >>> >>> USE_BINDING_FILTERS( >>> // the date-time binding filter >>> BINDING_FILTER("datetime", DateTimeBindingFilter) >>> ) >>> >>> however I don't quite understand where else in the code it is used. >>> My understanding is that the user in MeetingLine can only ask about >>> the last meeting or the previous meeting. There is no date or time >>> input by the user... so is the binding filter used? where? how? >>> >>> Do you have code examples that I can look at where the user is >>> actually speaking a date or number so I can see in the corresponding >>> request agent how that is handled and how the binding filter is >>> actually called? >>> >>> Is there any documentation on how BINDING_FILTER() works? >>> In the BindingFilters.cpp code there are comments referring to some >>> documentation, but in the version of MeetingLine we got from the >>> repository the Documentation folder in the solution is empty. Do you >>> have that file? Would that help and if so could you send it to me? >>> >>> >> >> >> > > From antoine at cs.cmu.edu Sun May 4 00:24:06 2008 From: antoine at cs.cmu.edu (Antoine Raux) Date: Sun, 04 May 2008 00:24:06 -0400 Subject: [Olympus developers 25]: Re: [Fwd: binding filters] In-Reply-To: <481D2E26.4070000@cs.cmu.edu> References: <4819EE5B.6010301@cs.cmu.edu> <481CFF91.10009@cs.cmu.edu> <481D2E26.4070000@cs.cmu.edu> Message-ID: <481D3A66.9050803@cs.cmu.edu> I completed the Binding Filters section in the Wiki (http://wiki.speech.cs.cmu.edu/olympus/index.php/RavenClaw_Grammar_Mappings_and_Binding_Filters#Binding_Filters). It should now give a pretty good idea of what binding filters are and how to use them (at least I hope so...). BTW, the MeetingLine system as it stands now does not use the datetime binding filter (it is declared in the CORE_CONFIGURATION and the function exists, but no grammar mapping uses ">:datetime"), which partly led to the confusion. I see that Thomas has just removed all the binding filter code from the MeetingLine repository, which is good :) antoine TK Harris wrote: > So there is some DateTime documentation on the wiki. It was an > orphaned page, as "Date Time". The list of components referred to > "DateTime". I changed the page name to match what's in the component > list, so you can now find it at: > http://wiki.speech.cs.cmu.edu/olympus/index.php/DateTime > > There's also the following documentation on binding filters: > http://wiki.speech.cs.cmu.edu/olympus/index.php/RavenClaw_Grammar_Mappings_and_Binding_Filters > > I just reworked that page so that it's a little easier to follow. > > -Thomas > > Brian Langner wrote: >> Any answers, guys? I'd really rather not make these people wait more >> than a week for a reasonable answer from us... >> >> Brian Langner wrote: >>> The group from Columbia that's building an Olympus system has a >>> question regarding binding filters - can someone help answer? >>> >>> Brian >>> >>> >>>> -------- Original Message -------- >>>> Subject: binding filters >>>> >>>> >>>> I'm still trying to understand how exactly do binding filters work >>>> within the dialog manager. >>>> The only example that I have is MeetingLine, and I see that it >>>> declares: >>>> >>>> USE_BINDING_FILTERS( >>>> // the date-time binding filter >>>> BINDING_FILTER("datetime", DateTimeBindingFilter) >>>> ) >>>> >>>> however I don't quite understand where else in the code it is used. >>>> My understanding is that the user in MeetingLine can only ask about >>>> the last meeting or the previous meeting. There is no date or time >>>> input by the user... so is the binding filter used? where? how? >>>> >>>> Do you have code examples that I can look at where the user is >>>> actually speaking a date or number so I can see in the >>>> corresponding request agent how that is handled and how the binding >>>> filter is actually called? >>>> >>>> Is there any documentation on how BINDING_FILTER() works? >>>> In the BindingFilters.cpp code there are comments referring to some >>>> documentation, but in the version of MeetingLine we got from the >>>> repository the Documentation folder in the solution is empty. Do >>>> you have that file? Would that help and if so could you send it to me? >>>> >>>> >>> >>> >>> >> >> > > From tkharris at cs.cmu.edu Sun May 4 00:48:42 2008 From: tkharris at cs.cmu.edu (TK Harris) Date: Sun, 04 May 2008 00:48:42 -0400 Subject: [Olympus developers 26]: cmucltk changes Message-ID: <481D402A.80108@cs.cmu.edu> Recent changes have broken the Visual Studio build of the cmucltk, which Olympus depends on. The stable 2.1 branch of Olympus is pegged to an older version of the toolkit, so for now only the trunk is affected. I see that Alex has improved the cygwin build so that it's well integrated with the linux builds, and yet builds native Windows executables, also it looks like there are binaries checked in. We can either 1) fix the VS build 2) just use checked-in executables 3) require cygwin for an Olympus build I don't really like any of these options; they each have some negatives. I'm open to suggestions. -Thomas From antoine at cs.cmu.edu Sun May 4 01:06:24 2008 From: antoine at cs.cmu.edu (Antoine Raux) Date: Sun, 04 May 2008 01:06:24 -0400 Subject: [Olympus developers 27]: Re: cmucltk changes In-Reply-To: <481D402A.80108@cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> Message-ID: <481D4450.8010205@cs.cmu.edu> Until we have a Linux version of Olympus, I'm in favor of not introducing a Cygwin dependency, so I prefer solution 1), although I don't know how hard that would be... antoine TK Harris wrote: > Recent changes have broken the Visual Studio build of the cmucltk, > which Olympus depends on. The stable 2.1 branch of Olympus is pegged > to an older version of the toolkit, so for now only the trunk is > affected. I see that Alex has improved the cygwin build so that it's > well integrated with the linux builds, and yet builds native Windows > executables, also it looks like there are binaries checked in. > We can either > 1) fix the VS build > 2) just use checked-in executables > 3) require cygwin for an Olympus build > > I don't really like any of these options; they each have some > negatives. I'm open to suggestions. > > -Thomas > From bfrisch at cs.cmu.edu Sun May 4 04:28:52 2008 From: bfrisch at cs.cmu.edu (Benjamin Frisch) Date: Sun, 4 May 2008 03:28:52 -0500 Subject: [Olympus developers 28]: Re: cmucltk changes In-Reply-To: <481D4450.8010205@cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> Message-ID: I am not in favor of introducing a Cygwin dependency as well; however, I understood the original message to imply that the rebuilt binaries do not require Cygwin to run. If the former is true I am ok with a VS Windows build being pushed off until 2.3; however, I think 1 is ideal if Cygwin/Unix support for the cmulmtk can be retained along with VS build support with relative ease in time for 2.2. (Perhaps, we need a test framework for this?) Ben On Sun, May 4, 2008 at 12:06 AM, Antoine Raux wrote: > Until we have a Linux version of Olympus, I'm in favor of not introducing a > Cygwin dependency, so I prefer solution 1), although I don't know how hard > that would be... > > antoine > > TK Harris wrote: > > > Recent changes have broken the Visual Studio build of the cmucltk, which > Olympus depends on. The stable 2.1 branch of Olympus is pegged to an older > version of the toolkit, so for now only the trunk is affected. I see that > Alex has improved the cygwin build so that it's well integrated with the > linux builds, and yet builds native Windows executables, also it looks like > there are binaries checked in. > > We can either > > 1) fix the VS build > > 2) just use checked-in executables > > 3) require cygwin for an Olympus build > > > > I don't really like any of these options; they each have some negatives. > I'm open to suggestions. > > > > -Thomas > > > > > > From tkharris at cs.cmu.edu Sun May 4 09:40:39 2008 From: tkharris at cs.cmu.edu (TK Harris) Date: Sun, 04 May 2008 09:40:39 -0400 Subject: [Olympus developers 29]: Re: cmucltk changes In-Reply-To: References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> Message-ID: <481DBCD7.5080609@cs.cmu.edu> A test framework doesn't help what I see are the real problems with (1) and (2), which are that developers need to develop in multiple environments regardless of whether the code changes involve os dependencies. This is already a problem for the sphinxes. As David says, "Every time I switch to Windows an angel dies". Even if an angel doesn't die, he's wasting his time. More often, I'm guessing that the build just gets broken, as happened recently with Alex's changes. (1) If we want to keep VS build stuff, in order to do any file structure changes (including simply adding a file) developers will need to have windows, visual studio, and linux (or cygwin). (2) This option is even worse. If we want to use binaries, _any_ change will require the developer to compile in windows and linux. Perhaps this is a good test case for a forth option: cmake or its ilk. -Thomas Benjamin Frisch wrote: > I am not in favor of introducing a Cygwin dependency as well; however, > I understood the original message to imply that the rebuilt binaries > do not require Cygwin to run. If the former is true I am ok with a VS > Windows build being pushed off until 2.3; however, I think 1 is ideal > if Cygwin/Unix support for the cmulmtk can be retained along with VS > build support with relative ease in time for 2.2. (Perhaps, we need a > test framework for this?) > > Ben > > On Sun, May 4, 2008 at 12:06 AM, Antoine Raux wrote: > >> Until we have a Linux version of Olympus, I'm in favor of not introducing a >> Cygwin dependency, so I prefer solution 1), although I don't know how hard >> that would be... >> >> antoine >> >> TK Harris wrote: >> >> >>> Recent changes have broken the Visual Studio build of the cmucltk, which >>> >> Olympus depends on. The stable 2.1 branch of Olympus is pegged to an older >> version of the toolkit, so for now only the trunk is affected. I see that >> Alex has improved the cygwin build so that it's well integrated with the >> linux builds, and yet builds native Windows executables, also it looks like >> there are binaries checked in. >> >>> We can either >>> 1) fix the VS build >>> 2) just use checked-in executables >>> 3) require cygwin for an Olympus build >>> >>> I don't really like any of these options; they each have some negatives. >>> >> I'm open to suggestions. >> >>> -Thomas >>> >>> >>> >> > > From Alex.Rudnicky at cs.cmu.edu Mon May 5 10:13:16 2008 From: Alex.Rudnicky at cs.cmu.edu (Alex Rudnicky) Date: Mon, 5 May 2008 10:13:16 -0400 Subject: [Olympus developers 30]: Re: cmucltk changes In-Reply-To: <481DBCD7.5080609@cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> <481DBCD7.5080609@cs.cmu.edu> Message-ID: <9C0D1A9F38D23E4290347EE31C22B0AF0200128D@e2k3.srv.cs.cmu.edu> Cmculmtk comes with compiled windows native and linux versions (available from sourceforge). There is no reason for an "end user" to work with the source code for this tool, so I think it's ok to just distribute binaries. (This is already necessary for the pronunciation code.) Cmuculmtk had to change because it contained library calls no longer supported by mainstream linux/gnu systems. It was also not structured all that well (I suspect that the latter is what's killing the VS build.) If someone does want to alter the code, the presumption should be that they know enough to deal with Cygwin and perl (if they don't, they shouldn't be fooling around down at that level). Alex -----Original Message----- From: olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu [mailto:olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On Behalf Of TK Harris Sent: Sunday, May 04, 2008 9:41 AM To: Benjamin Frisch Cc: Olympus Developers Subject: [Olympus developers 29]: Re: cmucltk changes A test framework doesn't help what I see are the real problems with (1) and (2), which are that developers need to develop in multiple environments regardless of whether the code changes involve os dependencies. This is already a problem for the sphinxes. As David says, "Every time I switch to Windows an angel dies". Even if an angel doesn't die, he's wasting his time. More often, I'm guessing that the build just gets broken, as happened recently with Alex's changes. (1) If we want to keep VS build stuff, in order to do any file structure changes (including simply adding a file) developers will need to have windows, visual studio, and linux (or cygwin). (2) This option is even worse. If we want to use binaries, _any_ change will require the developer to compile in windows and linux. Perhaps this is a good test case for a forth option: cmake or its ilk. -Thomas Benjamin Frisch wrote: > I am not in favor of introducing a Cygwin dependency as well; however, > I understood the original message to imply that the rebuilt binaries > do not require Cygwin to run. If the former is true I am ok with a VS > Windows build being pushed off until 2.3; however, I think 1 is ideal > if Cygwin/Unix support for the cmulmtk can be retained along with VS > build support with relative ease in time for 2.2. (Perhaps, we need a > test framework for this?) > > Ben > > On Sun, May 4, 2008 at 12:06 AM, Antoine Raux wrote: > >> Until we have a Linux version of Olympus, I'm in favor of not introducing a >> Cygwin dependency, so I prefer solution 1), although I don't know how hard >> that would be... >> >> antoine >> >> TK Harris wrote: >> >> >>> Recent changes have broken the Visual Studio build of the cmucltk, which >>> >> Olympus depends on. The stable 2.1 branch of Olympus is pegged to an older >> version of the toolkit, so for now only the trunk is affected. I see that >> Alex has improved the cygwin build so that it's well integrated with the >> linux builds, and yet builds native Windows executables, also it looks like >> there are binaries checked in. >> >>> We can either >>> 1) fix the VS build >>> 2) just use checked-in executables >>> 3) require cygwin for an Olympus build >>> >>> I don't really like any of these options; they each have some negatives. >>> >> I'm open to suggestions. >> >>> -Thomas >>> >>> >>> >> > > From tkharris at cs.cmu.edu Mon May 5 10:59:23 2008 From: tkharris at cs.cmu.edu (Thomas K Harris) Date: Mon, 05 May 2008 10:59:23 -0400 Subject: [Olympus developers 31]: Re: cmucltk changes In-Reply-To: <9C0D1A9F38D23E4290347EE31C22B0AF0200128D@e2k3.srv.cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> <481DBCD7.5080609@cs.cmu.edu> <9C0D1A9F38D23E4290347EE31C22B0AF0200128D@e2k3.srv.cs.cmu.edu> Message-ID: <481F20CB.3050205@cs.cmu.edu> An HTML attachment was scrubbed... URL: http://mailman.srv.cs.cmu.edu/pipermail/olympus-developers/attachments/20080505/2746273d/attachment-0001.html From antoine at cs.cmu.edu Mon May 5 11:14:45 2008 From: antoine at cs.cmu.edu (Antoine Raux) Date: Mon, 05 May 2008 11:14:45 -0400 Subject: [Olympus developers 32]: Re: cmucltk changes In-Reply-To: <481F20CB.3050205@cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> <481DBCD7.5080609@cs.cmu.edu> <9C0D1A9F38D23E4290347EE31C22B0AF0200128D@e2k3.srv.cs.cmu.edu> <481F20CB.3050205@cs.cmu.edu> Message-ID: <481F2465.8050900@cs.cmu.edu> I agree with going for option (2) for now. I think the long term solution to all these dependencies and Linux/Windows version issues is to make Olympus platform independent and (therefore) remove the VS dependency. Even a Cygwin dependency wouldn't be that bad if all of Olympus worked that way. The thing I don't like is to require people to have both Visual Studio and Cygwin (or whatever non-VS solution we can come up with for Windows). I believe that supporting Linux (again while keeping the possibility of running through Windows) will remove significant (if nothing else psychological) adoption barriers for a significant number of potential users. Of course, this is also a lot of work... Also, Thomas raised the issue of the additional burden put on CMUCLMTK developers to support VS. The question is: is Olympus the only user of CMUCLMTK requiring VS support? If there are indeed many people out there who compile the tk under VS then the issue goes beyond Olympus and the decision to support or not VS for cmuclmtk should take that into account. Again, that said, I'm okay with linking to Windows binaries for now. antoine Thomas K Harris wrote: > OK, so this is option (2), where every exported change by the > developers requires a compilation and repository check-in under both > windows and linux. I don't like reintroducing cygwin and linux into > the developers' requirements; presumption of knowledge > notwithstanding. But of course the other options have issues, too. > I'll make the necessary changes to Olympus to support this. > > BTW, We've put a lot of effort into making Olympus easier to use, but > I don't think of any current or near-team Olympus developer as an "end > user". I don't think Olympus is polished or robust enough yet, and as > an open-source and modular system, it encourages research development > in all its components. > > -Thomas > > Alex Rudnicky wrote: >> Cmculmtk comes with compiled windows native and linux versions >> (available from sourceforge). There is no reason for an "end user" to >> work with the source code for this tool, so I think it's ok to just >> distribute binaries. (This is already necessary for the pronunciation >> code.) >> >> Cmuculmtk had to change because it contained library calls no longer >> supported by mainstream linux/gnu systems. It was also not structured >> all that well (I suspect that the latter is what's killing the VS >> build.) >> >> If someone does want to alter the code, the presumption should be that >> they know enough to deal with Cygwin and perl (if they don't, they >> shouldn't be fooling around down at that level). >> >> Alex >> >> >> -----Original Message----- >> From: olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu >> [mailto:olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On Behalf >> Of TK Harris >> Sent: Sunday, May 04, 2008 9:41 AM >> To: Benjamin Frisch >> Cc: Olympus Developers >> Subject: [Olympus developers 29]: Re: cmucltk changes >> >> A test framework doesn't help what I see are the real problems with (1) >> and (2), which are that developers need to develop in multiple >> environments regardless of whether the code changes involve os >> dependencies. This is already a problem for the sphinxes. As David says, >> >> "Every time I switch to Windows an angel dies". Even if an angel doesn't >> >> die, he's wasting his time. More often, I'm guessing that the build just >> >> gets broken, as happened recently with Alex's changes. >> >> (1) If we want to keep VS build stuff, in order to do any file structure >> >> changes (including simply adding a file) developers will need to have >> windows, visual studio, and linux (or cygwin). >> (2) This option is even worse. If we want to use binaries, _any_ change >> will require the developer to compile in windows and linux. >> >> Perhaps this is a good test case for a forth option: cmake or its ilk. >> >> -Thomas >> >> Benjamin Frisch wrote: >> >>> I am not in favor of introducing a Cygwin dependency as well; however, >>> I understood the original message to imply that the rebuilt binaries >>> do not require Cygwin to run. If the former is true I am ok with a VS >>> Windows build being pushed off until 2.3; however, I think 1 is ideal >>> if Cygwin/Unix support for the cmulmtk can be retained along with VS >>> build support with relative ease in time for 2.2. (Perhaps, we need a >>> test framework for this?) >>> >>> Ben >>> >>> On Sun, May 4, 2008 at 12:06 AM, Antoine Raux >>> >> wrote: >> >>> >>> >>>> Until we have a Linux version of Olympus, I'm in favor of not >>>> >> introducing a >> >>>> Cygwin dependency, so I prefer solution 1), although I don't know how >>>> >> hard >> >>>> that would be... >>>> >>>> antoine >>>> >>>> TK Harris wrote: >>>> >>>> >>>> >>>>> Recent changes have broken the Visual Studio build of the cmucltk, >>>>> >> which >> >>>>> >>>>> >>>> Olympus depends on. The stable 2.1 branch of Olympus is pegged to an >>>> >> older >> >>>> version of the toolkit, so for now only the trunk is affected. I see >>>> >> that >> >>>> Alex has improved the cygwin build so that it's well integrated with >>>> >> the >> >>>> linux builds, and yet builds native Windows executables, also it >>>> >> looks like >> >>>> there are binaries checked in. >>>> >>>> >>>>> We can either >>>>> 1) fix the VS build >>>>> 2) just use checked-in executables >>>>> 3) require cygwin for an Olympus build >>>>> >>>>> I don't really like any of these options; they each have some >>>>> >> negatives. >> >>>>> >>>>> >>>> I'm open to suggestions. >>>> >>>> >>>>> -Thomas >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> > From Alex.Rudnicky at cs.cmu.edu Mon May 5 11:49:57 2008 From: Alex.Rudnicky at cs.cmu.edu (Alex Rudnicky) Date: Mon, 5 May 2008 11:49:57 -0400 Subject: [Olympus developers 33]: Re: cmucltk changes In-Reply-To: <481F20CB.3050205@cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> <481DBCD7.5080609@cs.cmu.edu> <9C0D1A9F38D23E4290347EE31C22B0AF0200128D@e2k3.srv.cs.cmu.edu> <481F20CB.3050205@cs.cmu.edu> Message-ID: <9C0D1A9F38D23E4290347EE31C22B0AF020012A1@e2k3.srv.cs.cmu.edu> I consider dialog system developers to be end users in this context, just as they are end users of ASR technology. VS is the problem dependency since it forces people to spend real money (~$700 for "Pro") in order to use our software. Alex From: Thomas K Harris [mailto:tkharris at cs.cmu.edu] Sent: Monday, May 05, 2008 10:59 AM To: Alex Rudnicky Cc: Olympus Developers Subject: Re: [Olympus developers 30]: Re: cmucltk changes OK, so this is option (2), where every exported change by the developers requires a compilation and repository check-in under both windows and linux. I don't like reintroducing cygwin and linux into the developers' requirements; presumption of knowledge notwithstanding. But of course the other options have issues, too. I'll make the necessary changes to Olympus to support this. BTW, We've put a lot of effort into making Olympus easier to use, but I don't think of any current or near-team Olympus developer as an "end user". I don't think Olympus is polished or robust enough yet, and as an open-source and modular system, it encourages research development in all its components. -Thomas Alex Rudnicky wrote: Cmculmtk comes with compiled windows native and linux versions (available from sourceforge). There is no reason for an "end user" to work with the source code for this tool, so I think it's ok to just distribute binaries. (This is already necessary for the pronunciation code.) Cmuculmtk had to change because it contained library calls no longer supported by mainstream linux/gnu systems. It was also not structured all that well (I suspect that the latter is what's killing the VS build.) If someone does want to alter the code, the presumption should be that they know enough to deal with Cygwin and perl (if they don't, they shouldn't be fooling around down at that level). Alex -----Original Message----- From: olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu [mailto:olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On Behalf Of TK Harris Sent: Sunday, May 04, 2008 9:41 AM To: Benjamin Frisch Cc: Olympus Developers Subject: [Olympus developers 29]: Re: cmucltk changes A test framework doesn't help what I see are the real problems with (1) and (2), which are that developers need to develop in multiple environments regardless of whether the code changes involve os dependencies. This is already a problem for the sphinxes. As David says, "Every time I switch to Windows an angel dies". Even if an angel doesn't die, he's wasting his time. More often, I'm guessing that the build just gets broken, as happened recently with Alex's changes. (1) If we want to keep VS build stuff, in order to do any file structure changes (including simply adding a file) developers will need to have windows, visual studio, and linux (or cygwin). (2) This option is even worse. If we want to use binaries, _any_ change will require the developer to compile in windows and linux. Perhaps this is a good test case for a forth option: cmake or its ilk. -Thomas Benjamin Frisch wrote: I am not in favor of introducing a Cygwin dependency as well; however, I understood the original message to imply that the rebuilt binaries do not require Cygwin to run. If the former is true I am ok with a VS Windows build being pushed off until 2.3; however, I think 1 is ideal if Cygwin/Unix support for the cmulmtk can be retained along with VS build support with relative ease in time for 2.2. (Perhaps, we need a test framework for this?) Ben On Sun, May 4, 2008 at 12:06 AM, Antoine Raux wrote: Until we have a Linux version of Olympus, I'm in favor of not introducing a Cygwin dependency, so I prefer solution 1), although I don't know how hard that would be... antoine TK Harris wrote: Recent changes have broken the Visual Studio build of the cmucltk, which Olympus depends on. The stable 2.1 branch of Olympus is pegged to an older version of the toolkit, so for now only the trunk is affected. I see that Alex has improved the cygwin build so that it's well integrated with the linux builds, and yet builds native Windows executables, also it looks like there are binaries checked in. We can either 1) fix the VS build 2) just use checked-in executables 3) require cygwin for an Olympus build I don't really like any of these options; they each have some negatives. I'm open to suggestions. -Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.srv.cs.cmu.edu/pipermail/olympus-developers/attachments/20080505/b8501f1f/attachment.html From tkharris at cs.cmu.edu Mon May 5 14:44:50 2008 From: tkharris at cs.cmu.edu (Thomas K Harris) Date: Mon, 05 May 2008 14:44:50 -0400 Subject: [Olympus developers 34]: Re: cmucltk changes In-Reply-To: <9C0D1A9F38D23E4290347EE31C22B0AF020012A1@e2k3.srv.cs.cmu.edu> References: <481D402A.80108@cs.cmu.edu> <481D4450.8010205@cs.cmu.edu> <481DBCD7.5080609@cs.cmu.edu> <9C0D1A9F38D23E4290347EE31C22B0AF0200128D@e2k3.srv.cs.cmu.edu> <481F20CB.3050205@cs.cmu.edu> <9C0D1A9F38D23E4290347EE31C22B0AF020012A1@e2k3.srv.cs.cmu.edu> Message-ID: <481F55A2.5020608@cs.cmu.edu> An HTML attachment was scrubbed... URL: http://mailman.srv.cs.cmu.edu/pipermail/olympus-developers/attachments/20080505/012ed2bf/attachment-0001.html From dhuggins at cs.cmu.edu Sat May 10 16:28:30 2008 From: dhuggins at cs.cmu.edu (David Huggins-Daines) Date: Sat, 10 May 2008 16:28:30 -0400 Subject: [Olympus developers 35]: Next release of PocketSphinx ready for integration and testing Message-ID: <4826056E.5070903@cs.cmu.edu> Hi everyone, New and exciting features include: * Word-level confidence estimation using posterior probabilities * N-best and confidence estimation work in both N-Gram and FSG modes * JSGF grammar support for the FSG decoder * Somewhat faster (3% on wsj5k on x86-64, but more on ARM, numbers forthcoming) * Considerably smaller code footprint (376k versus 801k on x86) * Wildly reduced memory footprint in single-pass mode (7.5MB vs. 14.7MB for wsj5k on x86-64) * Re-entrant API, multiple decoders can coexist in the same program I have created a branch in the Subversion repository for the future release. Its permanent home is: https://cmusphinx.svn.sourceforge.net/svnroot/cmusphinx/branches/pocketsphinx-0.5 Like the pocketsphinx-0.4 branch, this contains both pocketsphinx and sphinxbase, which will be released simultaneously. Documentation for the new API can be found at: http://www.speech.cs.cmu.edu/sphinx/doc/doxygen/pocketsphinx/ http://www.speech.cs.cmu.edu/sphinx/doc/doxygen/sphinxbase/ A migration guide is in progress (but certainly won't be done before Black Friday) at: http://www.speech.cs.cmu.edu/cmusphinx/moinmoin/PocketSphinxMigration From tkharris at cs.cmu.edu Wed May 21 10:45:29 2008 From: tkharris at cs.cmu.edu (TK Harris) Date: Wed, 21 May 2008 10:45:29 -0400 Subject: [Olympus developers 36]: in grammars Message-ID: <48343589.3080605@cs.cmu.edu> Hi, I'd like to mandate that the construct in grammars, e.g. [Repeat] (*sorry what's that *again) ( what ) (*sorry i didn't HEAR YOU) be forbidden. It's going to be a little awkward to support by some of the language tools, mostly because it's no longer context-free. It's caused problems in the past where gets treated like other vocabulary. My question is, are these non-context-free grammar elements too useful to simply remove? If so, then we might want to keep them, but change the syntax so that it doesn't overload the meaning of a token, relying on a side-effect of the recognizer. Thanks, -Thomas From Alex.Rudnicky at cs.cmu.edu Wed May 21 11:34:43 2008 From: Alex.Rudnicky at cs.cmu.edu (Alex Rudnicky) Date: Wed, 21 May 2008 11:34:43 -0400 Subject: [Olympus developers 37]: Re: in grammars In-Reply-To: <48343589.3080605@cs.cmu.edu> References: <48343589.3080605@cs.cmu.edu> Message-ID: <9C0D1A9F38D23E4290347EE31C22B0AF022BCDB2@e2k3.srv.cs.cmu.edu> I'm actually puzzled that the construct is being used at all. You get the same effect by making [Repeat] an entry net. Coercing an input into a single word is in any case iffy given that the speaker is not constrained in their productions. Or maybe I'm missing something here. Alex > -----Original Message----- > From: olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu > [mailto:olympus-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On Behalf > Of TK Harris > Sent: Wednesday, May 21, 2008 10:45 AM > To: Olympus Developers > Subject: [Olympus developers 36]: in grammars > > Hi, > > I'd like to mandate that the construct in grammars, e.g. > > [Repeat] > (*sorry what's that *again) > ( what ) > (*sorry i didn't HEAR YOU) > > be forbidden. It's going to be a little awkward to support by some of > the language tools, mostly because it's no longer context-free. It's > caused problems in the past where gets treated like other > vocabulary. My question is, are these non-context-free grammar elements > too useful to simply remove? If so, then we might want to keep them, > but > change the syntax so that it doesn't overload the meaning of a token, > relying on a side-effect of the recognizer. > > Thanks, > -Thomas From tkharris at cs.cmu.edu Wed May 21 13:49:51 2008 From: tkharris at cs.cmu.edu (Thomas K Harris) Date: Wed, 21 May 2008 13:49:51 -0400 Subject: [Olympus developers 38]: Re: in grammars In-Reply-To: <200805211534.m4LFYuGA021763@jackfruit.srv.cs.cmu.edu> References: <48343589.3080605@cs.cmu.edu> <200805211534.m4LFYuGA021763@jackfruit.srv.cs.cmu.edu> Message-ID: <483460BF.80907@cs.cmu.edu> An HTML attachment was scrubbed... URL: http://mailman.srv.cs.cmu.edu/pipermail/olympus-developers/attachments/20080521/4416eba5/attachment.html From tkharris at cs.cmu.edu Tue May 27 17:35:15 2008 From: tkharris at cs.cmu.edu (Thomas K Harris) Date: Tue, 27 May 2008 17:35:15 -0400 Subject: [Olympus developers 39]: machines will be shutdown in a few minutes Message-ID: <483C7E93.2000707@cs.cmu.edu> I'll be shutting down all the servers in a few minutes in prep for the power outage tonight. -Thomas