{12} export comments (26 matches)
| Ticket | Posixtime | Author | Newvalue | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #40 | 1260 | kowey | % Lexicon be betaVvPassive %(?A_1 ?C_1) equations:[interface.rel:focused interface.subjectI:?C_1] filters:[family:betaVvPassive ] semantics:[?A_1:focused(?C_1) ] % Grammar % ------------------------- TbetaVvPassive-2 betaVvPassive:TbetaVvPassive-2 ( ! rel:focused subjectI:?J ) auxiliary n0 [cat:"vp"]![assign-case:?A assign-comp:?B cat:"vp" mode:?C num:?D pers:?E tense:?F]{ n1 type:anchor [assign-case:?A assign-comp:?B cat:"v" mode:?C num:?D pers:?E tense:?F]![cat:"v" rmode:"ppart"] n2 type:foot [cat:"vp"]![cat:"vp" mode:"ppart" subject-idx:?J] } %semantics:[?M:?L(?J)] trace:[betaVv betaVvPassive passivePrag] % Suite tk semantics:[J:focused(D)] sentence:[A cake is baked by Bill] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #39 | 1311 | kowey | My writeup of this problem was not very clear. The problem is that if you plug in "cat:np" as a root feature instead of "[cat:np]", you get []. GenI should either explicitly reject it or just accept it sans square brackets as part of root feature input | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #37 | 1253 | kowey | That... wasn't too hard. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #35 | 1254 | kowey | Note that stupidmorph is done. We just need a round tuit to get it done for to-mmorph | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #32 | 1253 | kowey | You can tell that it's really nonsense, eg with RESULTS coming before AGENDA | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #32 | 1253 | kowey | Awesome: I can reproduce this with just the ej example and skipping one step at a time. I know that the internal GUI state is correct. Why are the widgets just not updating? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #32 | 1253 | kowey | Bleah! Well, I know how to make the symptoms go away, but I still don't ultimately know what the causes are. It's got something to do with setting selection on the list box (which causes the tail of my list to be appended to the front of it), but I can't reproduce it with a minimal demonstrator. All I know is that not setting the selection works around the problem... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #32 | 1253 | kowey | Fixed with: * Fix #32 (weird GUI bug with debugger). Yeah! There was something I was doing which was buggy. It really ought to be boiled down into a wxHaskell test case though because the outcome is really bizzare. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #31 | 1253 | kowey | It seems to be t150 in the XMG-GenI integration demo | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #31 | 1253 | kowey | In the debugger, it happens at iteration 142 (or 141?) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #31 | 1253 | kowey | I can confirm that GenI 0.17.4 makes it through this. So either this is a regression or something else has changed that reveals the error. If I understand correctly, this bug means we're trying to register more than one substitution for a variable, which doesn't make sense because normally once you've registered a substitution that variable is gone. I think this means that we're basically just failing to propagate substitutions somewhere... This makes me want a better abstraction over unification. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #31 | 1253 | kowey | Cool! This may not be a unification bug after all, but a repeated adjunction. Why are we getting this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #31 | 1253 | kowey | Resolved by: Fri Sep 25 17:16:00 CEST 2009 Eric Kow <E.Y.Kow@brighton.ac.uk> * Fix #31 - unification bug cause by failure to propagate. We do top and bottom unification after adjunction; however, the nodes that we were doing unification on did not have the latest substitutions from the adjunction test applied to them. I'm still not sure why this is a regression from GenI 0.17, but that's a future question to research. Note also that this bug would not have been caught without the pattern-matching style allowed by languages such as Haskell or one of the MLs. We simply would have silently accepted the anomalous situation and the user would have been none the wiser. I consider this a succesful application of the "Dead Programs Don't Lie" principle. So yay Haskell! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #30 | 1253 | kowey | Now called sillymorph. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #29 | 1252 | kowey | The workaround whilst waiting on this is to do morph realisation on the server side | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #29 | 1254 | kowey | Fixed with JSONification and API cleanup. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #23 | 1254 | kowey | Wontfix this. JSON is pretty useless for anything other than machine interchange -- no comments. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #19 | 1279 | dsf | Replying to [ticket:19 kowey]: > I'll have to see what Carlos thinks about it. Here is another vote for a license that would allow us to use GenI as a library in a commercial product. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #19 | 1311 | kowey | I think the official position is that we should keep it GPL for now and offer to dual license it commercially. The negotiations would be with INRIA, who are very understanding of the needs of startups and small businesses | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #14 | 1248 | kowey | Now that the feature is removed (and mandatory), is it good enough to pass in an empty feature structure? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9 | 1248 | kowey | Actually, all you have to do is to call the version of the program from the app bundle (geni.app/Contents/MacOS/geni) What would be nice is to not have to do that, though. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9 | 1253 | kowey | Fixed with my work to build an app bundle from Setup.hs | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #7 | 1252 | kowey | Alexandre has entry in his lexicon which looks like this: "chambre" n(?P ! gender:Fem) semantics:[participant(?P) objType(?P "chambre")] This represents as alternative workaround to the lack of percolation during morph realisation, which is to supply the morph features through the lexicon. According to Alex, this is not desirable. The information is redundant with that which is already present in the morphological lexicon. If we had feature percolation, then this would just work. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #7 | 1254 | kowey | This is actually quite easy to fix. It's a bug in the new standalone sillymorph package, which unifies each word independtly of the other. The right thing to do is not to mapM on the list monad (we use the list monad for prolog-style non-determinism because each word may have more than one realisation), but to foldM instead, passing in the unification variable substitutions along the way. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #5 | 1254 | kowey | The answer is JSON. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4 | 1254 | kowey | Input is UTF-8. Output should be locale-dependent as of GHC 6.12 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Note:
See TracReports for help on using and creating reports.
