No analysis since November 30th 2012 (Bugzilla Bug 1394)

[albbas]

This issue was created automatically with bugzilla2github

Bugzilla Bug 1394

Date: 2012-08-14T07:07:40+02:00 From: Trond Trosterud <> To: Lene Antonsen <> CC: berit.nystad.eskonsipo, borre.gaup, ciprian.gerstenberger, lene.antonsen, linda.wiechetek, ritva.nystad, sjur.n.moshagen, trond.trosterud

Last updated: 2013-01-25T10:13:22+01:00

[albbas]

Comment 6566

Date: 2012-08-14 07:07:40 +0200 From: Trond Trosterud <>

analysed$ls -lt | more total 47544 drwxrwxrwx+ 107 boerre staff 3638 19 jun 01:37 2012-06-18 drwxrwxrwx+ 107 boerre staff 3638 16 jun 01:26 2012-06-15 drwxrwxrwx+ 107 boerre staff 3638 14 jun 01:29 2012-06-13 drwxrwxrwx+ 107 boerre staff 3638 12 jun 01:51 2012-06-11 drwxrwxrwx+ 107 boerre staff 3638 9 jun 01:35 2012-06-08 drwxrwxrwx+ 107 boerre staff 3638 5 jun 01:51 2012-06-04 drwxrwxrwx+ 190 boerre staff 6460 2 jun 21:46 2012-06-01

Todo: Start the process.

[albbas]

Comment 6567

Date: 2012-08-14 07:32:08 +0200 From: Ciprian Gerstenberger <>

As for the parallel files, it is better not to just overwrite the existing files with the new ones. Many files have been moved from the orig/sme/ to orig/mixed/. These have to be removed altogether from the prestable. Then one wants to compare the existing files with results from the last run.

(In reply to comment #0)

Todo: Start the process.

[albbas]

Comment 6577

Date: 2012-08-14 15:54:34 +0200 From: Børre Gaup <>

(In reply to comment #0)

analysed$ls -lt | more total 47544 drwxrwxrwx+ 107 boerre staff 3638 19 jun 01:37 2012-06-18 drwxrwxrwx+ 107 boerre staff 3638 16 jun 01:26 2012-06-15 drwxrwxrwx+ 107 boerre staff 3638 14 jun 01:29 2012-06-13 drwxrwxrwx+ 107 boerre staff 3638 12 jun 01:51 2012-06-11 drwxrwxrwx+ 107 boerre staff 3638 9 jun 01:35 2012-06-08 drwxrwxrwx+ 107 boerre staff 3638 5 jun 01:51 2012-06-04 drwxrwxrwx+ 190 boerre staff 6460 2 jun 21:46 2012-06-01

Todo: Start the process.

I stopped the analysis then because some part of it uses so much memory that it crashes the xserve.

[albbas]

Comment 6589

Date: 2012-08-16 18:20:24 +0200 From: Trond Trosterud <>

... and it is still stopped. So, the XS is running, which is fine, but we need to have working corpora. Either:

• find out why the analysis is so memory-consuming, or
• move the analysis to e.g. stallo, the supercomputer.

The way of finding it out would be to measure analysis of different parts of the corpus and find out what causes the crashes.

There will come days when we need our analyses.

[albbas]

Comment 6619

Date: 2012-08-24 10:13:48 +0200 From: Trond Trosterud <>

So, now the day has come.

Which parts are memory-consuming?

Can the pipeline be changed? Does it use the "nice" prefix, for example?

I cannot see that it is impossible to split this process into manageable parts.

If it really is impossible, should we move to stallo?

Whatever the answers, we cannot just put this aside.

[albbas]

Comment 6657

Date: 2012-08-31 15:03:17 +0200 From: Trond Trosterud <>

The catastrophe actually came in two steps:

2. The pipeline stopped analyzing (18.6.)
3. The amount of text dropped from 23 mill to 3 mill (4.6.)

2012-06-18$cat smelookup2cg|grep '^"'|wc -l 3374159 2012-06-15$cat smelookup2cg|grep '^"'|wc -l 3374178 2012-06-13$cat smelookup2cg|grep '^"'|wc -l 3374160 2012-06-11$cat smelookup2cg|grep '^"'|wc -l 3374165 2012-06-08$cat smelookup2cg|grep '^"'|wc -l 3374164 2012-06-04$cat smelookup2cg|grep '^"'|wc -l 3374257 2012-06-01$cat sme*lookup2cg|grep '^"'|wc -l 23602859

The last analysed corpus is thus 2012-06-01. And this is where debugging should begin.

[albbas]

Comment 6802

Date: 2012-09-19 16:37:56 +0200 From: Lene Antonsen <>

Ikke alle filene har fått syntaktisk analyse, her er eksempel fra 15. juni, se forskjell mellom bible og news:

giellatekno:2012-06-15 lene$ ls sme-ne sme-news.ccat.txt sme-news.ccat.txt.lookup2cg

giellatekno:2012-06-15 lene$ ls sme-bi sme-bible.ccat.txt sme-bible.ccat.txt.lookup2cg
sme-bible.ccat.txt.dis sme-bible.dep.txt

[albbas]

Comment 6878

Date: 2012-09-21 14:27:15 +0200 From: Sjur Nørstebø Moshagen <>

It should be relatively easy to debug this given that we assume there is a bug in one of the pipeline components. It should also be possible to do it in between other things, since the corpus analysis is relatively time consuming, and the bug only manifests itself with large amounts of texts (I assume).

The strategy:

Reduce the pipeline to the first step only, and let it run for a day or two (whatever it takes to go through the whole corpus). Then add the next component, and redo. Keep adding things until the critical component is found.

It might as well take several rounds of analysis for each addition to actually trigger the bug. Memory leaks are hard to find. The only thing we know is that some component is exploding its memory consumption to the degree that the virtual memory swap files fills up the hard disk completely, and forces the server to a hard restart.

Børre, can you have a look at this, and start the debugging?

[albbas]

Comment 6928

Date: 2012-09-27 11:16:20 +0200 From: Børre Gaup <>

Cleaned up analyse--corpus.sh because of the changes newinfra brings. Started the analysis manually yesterday (It takes 48+ hours), still running today. No disasters so far.

[albbas]

Comment 6970

Date: 2012-09-29 08:13:06 +0200 From: Trond Trosterud <>

Here comes the disaster. No machine has gone down, but not much has been analysed either:

2012-09-26$ls sma-admin.ccat.txt sma-ficti.ccat.txt sma-nob-admin.ccat.txt sma-nob-facta.ccat.txt sma-sme-facta.ccat.txt sma-swe-facta.ccat.txt sma-swe-news.ccat.txt sma-facta.ccat.txt sma-nno-facta.ccat.txt sma-nob-bible.ccat.txt sma-nob-ficti.ccat.txt sma-swe-admin.ccat.txt sma-swe-ficti.ccat.txt

These are all and only the sma *ccat.txt files from may:

la ../2012-05-30/sma*ccat.txt ../2012-05-30/sma-admin.ccat.txt ../2012-05-30/sma-nno-facta.ccat.txt ../2012-05-30/sma-nob-facta.ccat.txt ../2012-05-30/sma-swe-admin.ccat.txt ../2012-05-30/sma-swe-news.ccat.txt ../2012-05-30/sma-facta.ccat.txt ../2012-05-30/sma-nob-admin.ccat.txt ../2012-05-30/sma-nob-ficti.ccat.txt ../2012-05-30/sma-swe-facta.ccat.txt ../2012-05-30/sma-ficti.ccat.txt ../2012-05-30/sma-nob-bible.ccat.txt ../2012-05-30/sma-sme-facta.ccat.txt ../2012-05-30/sma-swe-ficti.ccat.txt

So: no sme, no smj, and no analysis.

[albbas]

Comment 7001

Date: 2012-10-02 13:42:25 +0200 From: Børre Gaup <>

(In reply to comment #9)

Here comes the disaster. No machine has gone down, but not much has been analysed either:

2012-09-26$ls sma-admin.ccat.txt sma-ficti.ccat.txt sma-nob-admin.ccat.txt sma-nob-facta.ccat.txt sma-sme-facta.ccat.txt sma-swe-facta.ccat.txt sma-swe-news.ccat.txt sma-facta.ccat.txt sma-nno-facta.ccat.txt sma-nob-bible.ccat.txt sma-nob-ficti.ccat.txt sma-swe-admin.ccat.txt sma-swe-ficti.ccat.txt

These are all and only the sma *ccat.txt files from may:

la ../2012-05-30/sma*ccat.txt ../2012-05-30/sma-admin.ccat.txt ../2012-05-30/sma-nno-facta.ccat.txt ../2012-05-30/sma-nob-facta.ccat.txt ../2012-05-30/sma-swe-admin.ccat.txt ../2012-05-30/sma-swe-news.ccat.txt ../2012-05-30/sma-facta.ccat.txt ../2012-05-30/sma-nob-admin.ccat.txt ../2012-05-30/sma-nob-ficti.ccat.txt ../2012-05-30/sma-swe-facta.ccat.txt ../2012-05-30/sma-ficti.ccat.txt ../2012-05-30/sma-nob-bible.ccat.txt ../2012-05-30/sma-sme-facta.ccat.txt ../2012-05-30/sma-swe-ficti.ccat.txt

So: no sme, no smj, and no analysis.

The script ran for three days before I interrupted it, so there is some error in. I'll debug the script.

[albbas]

Comment 7003

Date: 2012-10-02 16:43:19 +0200 From: Børre Gaup <>

I have edited analyse-corpus.sh and fixed some errors in it.

I tested with smj on my own machine, and that worked as it should. The script is now running on divvun.no, it should be finished in about 2 days.

[albbas]

Comment 7008

Date: 2012-10-03 12:53:13 +0200 From: Børre Gaup <>

I stopped the script today at 11 o'clock. It hadn't produced any output since 2 a.m.

Here are the last lines of error output from it:

Warning: Hard limit of 500 cohorts reached at line 538634 - forcing break. Warning: Hard limit of 500 cohorts reached at line 541432 - forcing break. Warning: Hard limit of 500 cohorts reached at line 542447 - forcing break. Warning: Hard limit of 500 cohorts reached at line 543464 - forcing break. Warning: Hard limit of 500 cohorts reached at line 544477 - forcing break. Warning: Hard limit of 500 cohorts reached at line 546306 - forcing break. Warning: Hard limit of 500 cohorts reached at line 547322 - forcing break. Warning: Hard limit of 500 cohorts reached at line 548346 - forcing break. Warning: Hard limit of 500 cohorts reached at line 551538 - forcing break. Warning: Hard limit of 500 cohorts reached at line 552545 - forcing break. Warning: Hard limit of 500 cohorts reached at line 553571 - forcing break. panic: sv_setpvn called with negative strlen at /Users/boerre/gtsvn/gt/script/lookup2cg line 65, <> chunk 2553. panic: sv_setpvn called with negative strlen at /Users/boerre/gtsvn/gt/script/lookup2cg line 65, <> chunk 7362.

The last file the script wrote out is sme-news.ccat.txt.lookup2cg. It seems that lookup2cg doesn't like the input it is given. Further investigation ...

[albbas]

Comment 7061

Date: 2012-10-10 18:41:29 +0200 From: Trond Trosterud <>

... has shown what?

Still a discrepancy:

2012-10-02$wc -l ../2012-05-30/sme-.ccat.txt.dis 5491975 ../2012-05-30/sme-admin.ccat.txt.dis 366359 ../2012-05-30/sme-bible.ccat.txt.dis 5010 ../2012-05-30/sme-dan-facta.ccat.txt.dis 1831 ../2012-05-30/sme-eng-facta.ccat.txt.dis 2062490 ../2012-05-30/sme-facta.ccat.txt.dis 500830 ../2012-05-30/sme-ficti.ccat.txt.dis 23392 ../2012-05-30/sme-fin-admin.ccat.txt.dis 14176 ../2012-05-30/sme-fin-facta.ccat.txt.dis 77984 ../2012-05-30/sme-fin-ficti.ccat.txt.dis 809572 ../2012-05-30/sme-laws.ccat.txt.dis 26788807 ../2012-05-30/sme-news.ccat.txt.dis 77653 ../2012-05-30/sme-nno-admin.ccat.txt.dis 299000 ../2012-05-30/sme-nno-bible.ccat.txt.dis 137195 ../2012-05-30/sme-nno-facta.ccat.txt.dis 686 ../2012-05-30/sme-no-facta.ccat.txt.dis 11027585 ../2012-05-30/sme-nob-admin.ccat.txt.dis 554556 ../2012-05-30/sme-nob-bible.ccat.txt.dis 786412 ../2012-05-30/sme-nob-facta.ccat.txt.dis 1102788 ../2012-05-30/sme-nob-laws.ccat.txt.dis 2213 ../2012-05-30/sme-nob-news.ccat.txt.dis 13605 ../2012-05-30/sme-sme-admin.ccat.txt.dis 1223 ../2012-05-30/sme-sme-facta.ccat.txt.dis 50145342 total 2012-10-02$wc -l sme-.ccat.txt.dis 1521 sme-admin.ccat.txt.dis 366377 sme-bible.ccat.txt.dis 5010 sme-dan-facta.ccat.txt.dis 1831 sme-eng-facta.ccat.txt.dis 2006084 sme-facta.ccat.txt.dis 500915 sme-ficti.ccat.txt.dis 24185 sme-fin-admin.ccat.txt.dis 5644 sme-fin-facta.ccat.txt.dis 77992 sme-fin-ficti.ccat.txt.dis 15921 sme-laws.ccat.txt.dis 3005480 total 2012-10-02$

[albbas]

Comment 7068

Date: 2012-10-11 10:49:34 +0200 From: Børre Gaup <>

There were several errors in the script that hindered the analysis. All those errors should be fixed in langtech r63853 and r63853. A new run has been started, sma has already been analysed.

[albbas]

Comment 7076

Date: 2012-10-12 12:14:22 +0200 From: Børre Gaup <>

I started a test run of analyse-corpus.sh on both my machine and on the xserve. On my machine this run ended successfully, it is still running on the xserve. Since analyse-corpus.sh hasn't brought xserve down yet, I'll close this bug.

[albbas]

Comment 7077

Date: 2012-10-12 21:56:48 +0200 From: Børre Gaup <>

The cronjob running this script goes off on monday, wednesday and friday at 16.44.

[albbas]

Comment 7627

Date: 2013-01-02 13:55:10 +0100 From: Lene Antonsen <>

Nyeste analyse av korpuset på Divvun-serveren er 2012-11-30. Dvs. at korpuset ikke har vært analysert på en måned.

Jeg reåpner denne buggen, sjøl om det er en ny hendlese. Men kanskje er det nyttig informasjon her.

[albbas]

Comment 7675

Date: 2013-01-13 16:04:49 +0100 From: Lene Antonsen <>

Nå får vi ccat.txt.lookup2cg filer. Disse kan fungere som et utgangspunkt for syntaktisk analyse. Men lookup2cg fjerner en del analyser, den prioriterer leksikaliserte analyser framfor dynamisk sammensetning og derivasjon. Og den lager sammensatte ord av dynamiske sammensetninger.

Jeg foreslår at vi heller lagrer multi-filer, dvs med morfologisk analyse, men uten lookup2cg. Disse filene vil fungerer like raskt i syntaktisk analyse som dagens lookup2cg-filer, og dessuten vi man kunne søke etter derivasjoner og dynamiske sammensetninger med Der/ i førsteleddet, informasjon som er forsvunnet i lookup2cg-filene.

[albbas]

Comment 7676

Date: 2013-01-13 16:19:52 +0100 From: Lene Antonsen <>

Jeg trekker tilbake påstanden at lookup2cg-skriptet ikke tar tid. Men man kan lagre både og.

[albbas]

Comment 7679

Date: 2013-01-14 02:35:07 +0100 From: Børre Gaup <>

I stopped the analysis program on the xserve as it brings down the machine. We will have to move this process to a machine where doesn't take down important services.

[albbas]

Comment 7681

Date: 2013-01-14 08:36:30 +0100 From: Trond Trosterud <>

Yes. And preferably at once, since we will have a course on corpus usage on wednesday.

If we have to do it on another machine, then gtlab is a natural choice.

[albbas]

Comment 7724

Date: 2013-01-17 13:36:14 +0100 From: Børre Gaup <>

Closer analysis shows that it is vislcg3 that goes amok and uses all available memory.

One of the files that makes vislcg3 go amok is sme-laws.lookup2cg in analysed/2013-01-16

I sent one sentence at a time into vislcg3 using the program test-vislcg3.py (found in $GTHOME/gt/script)

One of the sentences that triggers this behaviour in vislcg3:

"" "doppe" Adv "" "son" Pron Pers Pl3 Loc "" "ii" V IV Neg Ind Pl3 "" "leat" V IV Ind Prs ConNeg "leat" V IV Ind Prs Pl1 "leat" V IV Inf "leat" V IV Ind Prs Sg2 "leat" V IV Ind Prs Pl3 "" "gustot" V IV Der/NomAg N Sg Gen "gustot" V IV PrsPrc Der/A A Attr "gustot" V IV PrsPrc "gustot" V IV Der/NomAg N Sg Nom "gustojeaddji" A Sg Gen "gustojeaddji" A Sg Acc "gustot" V IV Der/NomAg N Sg Acc "gustojeaddji" A Sg Nom "gustojeaddji" A Attr "<lágaid>" "láhka" N Pl Gen "lága" N Pl Acc "lága" N Pl Gen "láhka" N Pl Acc "<vuođul>" "vuođul" Po "<makkárge>" "makkárge" Pron Indef Attr "makkárge" Pron Indef Sg Nom "<earenoamáš>" "erenoamáš" A Sg Gen "erenoamáš" A Attr "erenoamáš" A Sg Acc "erenoamáš" A Sg Nom "<vuoigatvuođat>" "vuoigat" A Der/vuohta N Sg Gen PxSg2 "vuoigat" A Der/vuohta N Sg Acc PxSg2 "vuoigat" A Der/vuohta N Pl Nom "vuoigatvuohta" N Sg Acc PxSg2 "vuoigatvuohta" N Sg Gen PxSg2 "vuoigatvuohta" N Pl Nom "" "vaikko" CS "vaikko" Adv "" "leat" V IV Ind Prs ConNeg "leat" V IV Ind Prs Pl1 "leat" V IV Inf "leat" V IV Ind Prs Sg2 "leat" V IV Ind Prs Pl3 "" "guovlu" Plc N Pl Gen "guovlu" Plc N Pl Acc "" "geavvat" V IV Der/h V TV PrfPrc "geavvat" V IV Ind Prs ConNeg Foc/han "geavvat" V IV Der/h V TV Ind Prt ConNeg "geavvat" V IV Der/h V TV Ind Prs Sg1 "geavahit" V TV Ind Prt ConNeg "geavahit" V TV Actio Nom "geavahit" V TV Ind Prs Sg1 "geavahit" V TV PrfPrc "geavvat" V IV Der/h V TV Actio Nom "geavvat" V IV* Der/h V TV Actio Gen "geavvat" V IV VGen Foc/han "geavahit" V TV Actio Gen "<ealáhusoaiviliin>" "ealáhus#oaivil" N Sg Com "ealáhus#oaivil" N Pl Loc "<čuđiid>" "čuohti" Num Pl Acc "čuođi" Num Pl Gen "čuđđi" Hum N Pl Acc "čuohti" N Pl Acc "čuođi" Num Pl Ill Attr "čuđđi" Hum N Pl Gen "čuođi" Num Pl Com Attr "čuohti" N Pl Gen "čuohti" Num Pl Ill Attr "čuođi" Num Pl Acc "čuhti" Hum N Pl Gen "čuohti" Num Pl Com Attr "čuohti" Num Pl Gen "čuhti" Hum N Pl Acc "" "jahki" Time N Pl Acc "jahki" Time N Pl Gen "<.>" "." CLB

[albbas]

Comment 7726

Date: 2013-01-17 20:14:37 +0100 From: Lene Antonsen <>

Setninga fungerer helt normalt lokalt på min maskin, både når jeg analyserer kun den, og når jeg analyserer den som en del av et mindre korpus. Kan problemet være at korpuset blir ei for stor fil på en gang?

[albbas]

Comment 7727

Date: 2013-01-17 21:57:32 +0100 From: Ciprian Gerstenberger <>

Når jeg prøver Børres med bare denne setning i input fila får jeg dette:

================= gogo>python ~/main/gt/script/test-vislcg3.py test_sent.txt 1 93 all hell

VISL CG-3 Disambiguator version 0.9.7.5129 Codepage: default UTF-8, input UTF-8, output UTF-8, grammar UTF-8 Error: Attempted to reference undefined set 'SUB:1' on line 2857!

Er det kanskje noe med ulike VISL-versjoner å gjøre?

(In reply to comment #23)

Setninga fungerer helt normalt lokalt på min maskin, både når jeg analyserer kun den, og når jeg analyserer den som en del av et mindre korpus. Kan problemet være at korpuset blir ei for stor fil på en gang?

[albbas]

Comment 7728

Date: 2013-01-17 22:35:17 +0100 From: Trond Trosterud <>

Ja, det er eit spørsmål om vislcg3-versjon, og din er svært gammal.

tf-hsl-m0016:vislcg3 ttr000$ vislcg3 -V VISL CG-3 Disambiguator version 0.9.8.8752 Copyright (C) 2007-2012 GrammarSoft ApS. All Rights Reserved.

Med ein nyare versjon går feilmeldinga bort.

[albbas]

Comment 7729

Date: 2013-01-17 23:17:51 +0100 From: Lene Antonsen <>

(In reply to comment #23)

Setninga fungerer helt normalt lokalt på min maskin, både når jeg analyserer kun den, og når jeg analyserer den som en del av et mindre korpus.

Nå har jeg oppdatert min vislcgversjon: VISL CG-3 Disambiguator version 0.9.8.8752

Og nå får jeg problemer med den nevnte setninga. Så det må være en bug i den nyeste vislcg3-versjonen.

[albbas]

Comment 7730

Date: 2013-01-17 23:24:15 +0100 From: Lene Antonsen <>

smedis "Doppe sis eai leat gustojeaddji lágaid vuođul makkárge earenoamáš vuoigatvuođat vaikko leat guovlluid geavahan ealáhusoaiviliin čuđiid jagiid."

Poblemet er ordet čuđiid. Hvis jeg bytter det ut med et annet tallord som ikke har N analyse, f.eks. viđaid, så går analysen bra. Men med ord som både gir Num og N analyser, stopper vislcg3 opp. Sannsynligvis går den i loop.

[albbas]

Comment 7731

Date: 2013-01-18 00:26:14 +0100 From: Lene Antonsen <>

Har testa litt. I nevnte setninger er det denne analysen som lager problemer:

"<čuđiid>" "čuđđi" Hum N Pl Acc "čuohti" N Pl Acc <=========== "čuohti" Num Pl Gen "čuhti" Hum N Pl Acc "čuođi" Num Pl Com Attr "čuođi" Num Pl Ill Attr "čuohti" N Pl Gen "čuđđi" Hum N Pl Gen "čuohti" Num Pl Acc "čuođi" Num Pl Gen "čuohti" Num Pl Ill Attr "čuođi" Num Pl Acc "čuhti" Hum N Pl Gen "čuohti" Num Pl Com Attr

Hvis jeg fjerner denne analysen, fungerer vislcg3. Skal se nærmere på dette i morgen.

[albbas]

Comment 7732

Date: 2013-01-18 00:29:23 +0100 From: Lene Antonsen <>

(In reply to comment #28)

Har testa litt. I nevnte setninger er det denne analysen som lager problemer:

"<čuđiid>" "čuđđi" Hum N Pl Acc "čuohti" N Pl Acc <=========== "čuohti" Num Pl Gen "čuhti" Hum N Pl Acc "čuođi" Num Pl Com Attr "čuođi" Num Pl Ill Attr "čuohti" N Pl Gen "čuđđi" Hum N Pl Gen "čuohti" Num Pl Acc "čuođi" Num Pl Gen "čuohti" Num Pl Ill Attr "čuođi" Num Pl Acc "čuhti" Hum N Pl Gen "čuohti" Num Pl Com Attr

Kombinert med denne:

"" "guovlu" Plc N Pl Acc <===== "guovlu" Plc N Pl Gen

Hvis den ene av disse to fjernes, fungerer vislcg3.

[albbas]

Comment 7733

Date: 2013-01-18 07:39:38 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to comment #27)

Poblemet er ordet čuđiid. Hvis jeg bytter det ut med et annet tallord som ikke har N analyse, f.eks. viđaid, så går analysen bra. Men med ord som både gir Num og N analyser, stopper vislcg3 opp. Sannsynligvis går den i loop.

Vislcg3 skal uansett ikkje gå inn i ei løkke. Problemet bør rapporterast til Tino, i lag med vislcg3-versjon og nok data til å gjenskapa problemet.

[albbas]

Comment 7734

Date: 2013-01-18 08:48:40 +0100 From: Lene Antonsen <>

Vislcg3 skal uansett ikkje gå inn i ei løkke. Problemet bør rapporterast til Tino, i lag med vislcg3-versjon og nok data til å gjenskapa problemet.

Jo, det skal jeg gjøre. Jeg har eksperimentert litt og problemet er i denne regelen:

MAP:IfNoTransV< (@OBJ>) TARGET Acc - ("dat" Dem) IF (NEGATE -1 V-TRANS-ACT-NOT-ACT BARRIER S-BOUNDARY2 LINK 0 FMAINV)(NEGATE 0 OBJ + Inf LINK -1 CC LINK -1 OBJ + Inf)(NEGATE 1 COMMA LINK 1 TV)(NEGATE 1 (@Num<) BARRIER NOT-ADJ LINK 1 @>P LINK 1 @<ADVL) ;

Men problemet er altså bare i ny versjon av vislcg3.

[albbas]

Comment 7735

Date: 2013-01-18 08:55:53 +0100 From: Lene Antonsen <>

Jeg har elimenert videre. Problemet med regelen i forhold til ny vislcg3 er faktisk

MAP (@OBJ>)

Hvis jeg bytter ut denne med MAP (@SUBJ>), så fungerer alt som det skal.

[albbas]

Comment 7736

Date: 2013-01-18 09:18:44 +0100 From: Lene Antonsen <>

Created attachment 153 Fil for testing med vislcg3

Fil for testing med vislcg3 for å se om problemet er lokalt i min maskin.

Attached file: sentence (text/plain, 2233 bytes) Description: Fil for testing med vislcg3

[albbas]

Comment 7737

Date: 2013-01-18 09:42:14 +0100 From: Trond Trosterud <>

Nei, det er ikkje lokalt på di maskin. Eg får same problem:

• på mi maskin, VISL CG-3 Disambiguator version 0.9.8.8752
• på gtlab: VISL CG-3 Disambiguator version 0.9.7.8306

[albbas]

Comment 7746

Date: 2013-01-21 16:10:37 +0100 From: Børre Gaup <>

Jeg prøvde å sjekke ut eldre versjoner av vislcg3 og bruke sme-dis.rle mot setninga til Lene. Jeg prøvde å kompilere r7000, r7500, r7596, r7597, r7598, r7599, 7600, 7750, 8000, 8808

Den eldste versjonen som gikk i gang uten å protestere mot sme-dis.rle er 7597. Alle versjonene som fungerte viste samme oppførsel, de brukte masse minne.

[albbas]

Comment 7747

Date: 2013-01-22 12:10:26 +0100 From: Børre Gaup <>

VISL CG-3 Disambiguator version 0.9.8.8810 viser fremdeles samme oppførsel som før på min maskin (masse minnebruk)

[albbas]

Comment 7751

Date: 2013-01-22 14:00:54 +0100 From: Lene Antonsen <>

Jeg har sendt mail til Tino med kopi til Børre og Trond.

[albbas]

Comment 7752

Date: 2013-01-22 16:01:16 +0100 From: Lene Antonsen <>

Svar fra Tino:

Not a CG-3 bug! Der er en loop i reglerne.

Regel 16650 SUBSTITUTE (Acc @<OBJ) (Acc @APP-N<) (N) (-1 (N Acc @<OBJ))(1 EOC) ; Regel 16401 SELECT:r3528 @ADVL IF (*-2 OBJ BARRIER S-BOUNDARY2 OR Pr)(-1 NUMERALS)(0 TIME OR MEASURE);

Substitute matcher N og derefter sletter tags Acc @<OBJ hvis de eksisterer, og derefter tilføjer tags Acc @APP-N< Select fjerner så @APP-N< læsningen. Repeat until infinity.

Ret regel 16650 til SUBSTITUTE (Acc @<OBJ) (Acc @APP-N<) (N Acc @<OBJ) (-1 (N Acc @<OBJ))(1 EOC) ; ...altså tilføj Acc @<OBJ i target.

Substitute kræver ikke at de tags den fjerner faktisk eksisterer - for at kræve det skal de være i target. Sådan virkede vislcg også.

---

Jeg skal se på alle substitutereglene.

[albbas]

Comment 7753

Date: 2013-01-22 16:39:52 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to comment #38)

Svar fra Tino:

Not a CG-3 bug! Der er en loop i reglerne. ... Substitute kræver ikke at de tags den fjerner faktisk eksisterer - for at kræve det skal de være i target. Sådan virkede vislcg også.

Ein kan sjølvsagt hevda at vislcg3 burde stoppa slike regelløkker, dvs merka at noko går gale, og deretter ta seg sjølv ned på ein pen måte. Det er ikkje vakkert når heile XServen går ned (men ein kan òg hevda at regelskrivarane må ta andsvar for reglane sine, eller at Apple burde stoppa slike prosessar utan at heile maskina går ned).

Du kan jo skriva attende og be om ein 'feature request' - dersom minnebruken går kraftig opp (eller ein annan indikator), så bør vislcg3 avslutta seg sjølv med ei feilmelding, ev. i lag med dei N sist brukte reglane. Eg reknar med at det ikkje alltid er lett å sjå slike løkker, og då vil det vera ei hjelp om vislcg3 seier i frå - på ein eller annan måte.

[albbas]

Comment 7754

Date: 2013-01-22 20:19:57 +0100 From: Lene Antonsen <>

Jeg har ikke vært klar over at SUBSTITUTE-reglene fungerer slik som Tino beskriver. Nå her jeg sett gjennom sme-dis.rle-fila og lagt til taggen som skal fjernes til target i alle Substitute-reglene.

svn ci -m "Har presisert target i alle SUBSTITUTE-reglene, håper at vi unngår loop." src/sme-dis.rle Sending src/sme-dis.rle Transmitting file data . Committed revision 68644.

[albbas]

Comment 7762

Date: 2013-01-23 22:38:46 +0100 From: Lene Antonsen <>

Børre, har du testa analyseringa? Om det går bedre etter mine endringer av sme-dis.rle:

[albbas]

Comment 7763

Date: 2013-01-24 09:14:39 +0100 From: Børre Gaup <>

Jeg har satt i gang en analyse nå, så får vi håpe det går bra :)

[albbas]

Comment 7764

Date: 2013-01-24 09:45:51 +0100 From: Trond Trosterud <>

1. Analyserer du på xserve eller gtlab?
2. Viss du analyserer på xserve, har du sett på oppsett for å analysere på gtlab?

Det er viktig at vi startar prosessen, både for resultatet sin del og fordi vi vil teste korleis det går. Så det er riktig å starte på xserve.

For min del må det gjerne forbli på xserve, men dette er tydelegvis ein prosess der vi risikerer minnelekkasje, så det talar kanskje for gtlab, eller eigentleg for stallo.

[albbas]

Comment 7766

Date: 2013-01-24 10:45:18 +0100 From: Børre Gaup <>

Jeg kjører analysen på min egen maskin nå.

Hvis det ikke er noe problem, setter jeg bygging av korpus og analyse opp på gtlab. Jeg vil ikke bruke xserve, fordi vislcg3 har tatt ned den maskinen så mange ganger.

[albbas]

Comment 7768

Date: 2013-01-25 10:13:22 +0100 From: Børre Gaup <>

Analysen går uten problemer nå etter at Lene fikset sme-dis.rle. Konvertering av free- og boundcorpus + analyse er satt opp på gtlab. Analysen blir startet på ettermiddagen mandag, onsdag og fredag