Den middels store LaTeX-tråden

[kyrsjo]

*snip*

mini-templates for figurer, tabeller etc.,

Dette får du jo med AUCTeX? For øvrig har Org-mode noen veldig nyttige funksjoner for å konvertere fra lettredigert «ASCII-art» til den grusomme tabellsyntaksen til LaTeX.

*snip*

 

Med eclipse trykker jeg bare control-mellomrom så spretter det opp en meny med forslag. Hurtigfullfører ting gjør den også. Merk-ESC-Q fikser wordwrappingen i kildefila.

 

Dette er helt sikkert mulig å få til med emacs også (som jeg bruker for det meste annet av editerings-behov), men jeg synes ofte jeg bruker mer tid på *emacs* enn på å *skrive*...

 

Dessuten insisterer AucTex på å skrive tegn etter _ og ^ i mattemodus med litt mindre (kortere) font,

noe som ødelegger poenget med monospace...

 

*snip*

valg av alternativ latex-distro

AUCTeX har (require 'tex-mik) og (require 'tex-fptex) for skreddersydde oppsett for MiKTeX and fpTeX. Men det var kanskje ikke det du siktet til?

 

Nei, bruker TeTeX, men har to distribusjoner installert (don't ask...). Dessverre ligger distribusjonen i /local/bin "forran" i PATH, mens jeg ønsker å bruke en distribusjon i /usr/bin (og ønsker ikke å tulle *ennå* mer med $PATH-variabelen).

 

Poenget var mer det at eclipse gjerne forteller deg hvordan man gjør ting, mens emacs somregel krever googling eller noen til å fortelle deg hvilken obskur streng med LISP-kode man må dytte inn på M-x eller .emacs.

[....]

Med eclipse trykker jeg bare control-mellomrom så spretter det opp en meny med forslag. Hurtigfullfører ting gjør den også.

For miljøer: C-c C-e <tab>. For ord: M-/ (<tab> i nyere versjoner av Emacs).

 

Merk-ESC-Q fikser wordwrappingen i kildefila.

M-q.

 

Dessuten insisterer AucTex på å skrive tegn etter _ og ^ i mattemodus med litt mindre (kortere) font,

noe som ødelegger poenget med monospace...

Jeg synes det gjør koden mer leselig, men det kan deaktiveres med (setq-default font-latex-fontify-script nil).

 

Poenget var mer det at eclipse gjerne forteller deg hvordan man gjør ting, mens emacs somregel krever googling eller noen til å fortelle deg hvilken obskur streng med LISP-kode man må dytte inn på M-x eller .emacs.

Leser bare Info-manualen, jeg

Endret 3. januar 2012 av ....

[kyrsjo]

 

Dessuten insisterer AucTex på å skrive tegn etter _ og ^ i mattemodus med litt mindre (kortere) font,

noe som ødelegger poenget med monospace...

Jeg synes det gjør koden mer leselig, men det kan deaktiveres med (setq-default font-latex-fontify-script nil).

 

Den perfekte løsningen hadde dog vært å beholde *lengden* på tegnene, men gjort dem mindre og justert dem opp eller ned...

 

Poenget var mer det at eclipse gjerne forteller deg hvordan man gjør ting, mens emacs somregel krever googling eller noen til å fortelle deg hvilken obskur streng med LISP-kode man må dytte inn på M-x eller .emacs.

Leser bare Info-manualen, jeg

 

Det går fint (tenkte ikke at auctex hadde manualen sin under info... Burde vel ha gjetta den.), men med Eclipse så er det stort sett opplagt

[....]

Kva versjonskontroll angår, har eg aldri brukt det, men eg ser at det kan vere fornuftig, so eg må tenkje på det.

Versjonskontroll høres interessant ut, men er ikke noe jeg har ressurser til å sette meg inn i i øyeblikket.

OK – etter å ha lest dette innlegget, skal dere vite alt dere trenger for å begynne med versjonskontroll.

 

Før vi begynner, installer Mercurial eller Git (msysGit på Windows), samt TortoiseHg eller TortoiseGit. De siste er ikke strengt nødvendige, men gir et felles brukergrensesnitt, slik at du kan følge denne veiledningen uansett hva du velger.

 

Første steg er å initialisere et repository. Høyreklikk på prosjektmappen din og velg «Create repository here»:

 

 

I tillegg må vi inn i mappen, markere de aktuelle filene og legge dem til. (Du kan ha filer i repo’et ditt som ikke er under versjonskontroll: De vises med et blått spørsmålstegn, som under.) Her høyreklikker vi på catch22.tex og velger «TortoiseGit → Add»:

 

 

Da er vi klare! Filen er nå grønn, ettersom de siste endringene er sjekket inn:

 

 

La oss gjøre noen nye endringer. Vi åpner catch22.tex i en teksteditor, legger til litt tekst og lagrer:

 

 

Nå blir filen rød, fordi det er avvik mellom den og det som er sjekket inn siden sist. For å sjekke inn, høyreklikker vi på filen (eller den overordnede mappen) og velger «Commit»:

 

 

Vi får opp et tekstfelt hvor kan skrive et kort sammendrag av hva vi har gjort:

 

 

Suksess! Filen er nå oppdatert og grønn igjen.

 

 

Stort mer er det ikke. Du kan opprette en konto på GitHub eller BitBucket og synkronisere arbeidet ditt mot en ekstern server, men i utgangspunktet gjøres alt lokalt (distribuert). Du sjekker inn arbeidet ditt så ofte du føler for det, kanskje ved arbeidsdagens slutt. For å se hvordan prosjektet skrider fremover, høyreklikk på filen/mappen og velg «TortoiseGit → Show log».

 

Lykke til!

 

(Fortsatt ikke overbevist? Les om fordelene med versjonskontroll.)

Endret 3. januar 2012 av ....

[Frexxia]

Er det noen her (antar det) som vet hva som er god skikk når man skal skrive et spekter av tall? Skriver man f.eks 0,1 A-5 A eller 0,1-5 A?

[....]

Skriver man f.eks 0,1 A-5 A eller 0,1-5 A?

0,1--5~A. (Bruk icomma-pakken dersom du ønsker komma som desimalskilletegn i mattemodus.)

Endret 3. januar 2012 av ....

[Torbjørn T.]

longwinded:

Takker.

 

Frexxia:

Eg veit eigentleg ikkje, men siunitx har ein \SIrange-kommando for slikt, og der kan ein, so vidt eg hugser, velge mellom å setje tala i parentes, med eining etterpå, eller ha eining på kvart tal, dvs. noko som (0,1-0,5)A eller 0,1A-0,5A.

 

Red.: Noko seint ute ja, ikkje høyr på meg.

Endret 20. april 2010 av Torbjørn T.

[Frexxia]

Jeg bruker \sisetup{decimalsymbol=comma, expproduct=cdot, digitsep=0} og \DeclareMathSymbol{.}{\mathpunct}{letters}{"3A}

 

\DeclareMathSymbol{,}{\mathord}{letters}{"3B}.

 

Er det minus eller bindestrek som skal brukes? Disse har ganske forskjellig lengde.

 

edit:

...

Eg veit eigentleg ikkje, men siunitx har ein \SIrange-kommando for slikt, og der kan ein, so vidt eg hugser, velge mellom å setje tala i parentes, med eining etterpå, eller ha eining på kvart tal, dvs. noko som (0,1-0,5)A eller 0,1A-0,5A.

...

Skal sjekke ut den.

 

edit2:

SIrange gir ut f.eks "0,1 A to 5 A", så med mindre det kan endres på er den ikke aktuell til mitt bruk.

Endret 20. april 2010 av Frexxia

[....]

Er det minus eller bindestrek som skal brukes? Disse har ganske forskjellig lengde.

Ingen av delene. Du bruker en intervallstrek, --. Også kjent som tankestrek.

Endret 3. januar 2012 av ....

[Torbjørn T.]

edit2:

SIrange gir ut f.eks "0,1 A to 5 A", så med mindre det kan endres på er den ikke aktuell til mitt bruk.

Er berre å lese bruksanvisninga: http://tug.ctan.org/tex-archive/macros/latex/contrib/siunitx/siunitx.pdf

 

Legg til tophrase=dash i \sisetup. Er andre alternativ, sjekk seksjon 8 i bruksanvisninga.

[Rusma]

Takk for et kjempebra og langt svar. Jeg har arbeidet med å lage strukturformlene videre idag utfra samme eksempel. Resultatet ble slik:

lengden på alle pinnene går ut fra en variabel jeg har kalt \storleik.

Redigert 2:

pgfmanual.pdf er forøvrig eit veldig nyttig dokument å ha om ein skal bruke PGF/Tikz. Veldig mykje informasjon, og mange døme.

 

Nokon feil er det dessverre. I starten er det fire guider som tek for seg konstruksjonen av fire ulike figurar frå starten av. I den andre av desse («A Petri-Net for Hagen», kapittel 3) er det eit avsnitt (avsnitt 3.8) som omhandlar relativ plassering av noder, slik eg har gjort over. Feilen her er at det står ein må bruke placements-biblioteket, medan det eigentleg er positioning-biblioteket som er aktuelt, jfr. dømet mitt over.

 

Og berre for ordens skuld legg eg inn link til Texample.com ein gong til:

http://www.texample.net/tikz/examples/

 

Når eg laga dømet brukte eg fyrst pgfmanual.pdf, men då fekk eg det naturleg nok ikkje til å fungere, sidan placements-biblioteket ikkje eksisterer ein gong. So då såg eg på eit døme under «node positioning» på Texample, og fann raskt at det var positioning-biblioteket eg måtte ha.

 

Det kan vere placements er gamalt, frå ein eldre versjon av Tikz, og so har ikkje manualen vorte oppdatert heilt, men det veit eg ikkje.

 

Blir TikZ forandret veldig etter hver oppdatering, så dokumenter man skrev for en god tid tilbake, ikke lengre kan kompileres fordi koden er "gammel"? Eller var det fordi du måtte friske litt opp her i sted?

 

Texample ser ut til å være en flott side. rna-cordons-table så litt overveldende ut. Vet ikke helt hvor jeg skal begynne. Må man ha noe forhåndskunnskaper (annet enn å se i manualen)? Jeg kjenner litt til hvordan man trekker streker, slår sirkler og lignende enkle geometriske objekter i ActionScript (Adobe Flash).

[Rusma]

OK – etter å ha lest dette innlegget, skal dere vite alt dere trenger for å begynne med versjonskontroll.

 

Før vi begynner, installer Mercurial eller Git (msysGit på Windows), samt TortoiseHg eller TortoiseGit. De siste er ikke strengt nødvendige, men gir et felles brukergrensesnitt, slik at du kan følge denne veiledningen uansett hva du velger.

 

[...]

 

Flott innlegg!

 

Til nå har jeg synes dette med versjonskontrollsystemer har vært litt uklart, men dette hjalp virkelig på.

 

Det finnes jo mange andre versjonskontrollsystemer. Subversion er vel et, og CVS ... Hva vil du si er forskjellen mellom Mercurial og Git? Det virker som om begge er populære.

[....]

Til nå har jeg synes dette med versjonskontrollsystemer har vært litt uklart, men dette hjalp virkelig på.

Hurra!

 

For øvrig har jo de fleste har vært borti noe lignende på Wikipedia. Har du redigert en artikkel på Wikipedia, har du brukt versjonskontroll.

 

Det finnes jo mange andre versjonskontrollsystemer. Subversion er vel et, og CVS ...

Styr langt unna Subversion og CVS. De er sentraliserte, som vil si at du må koble til en server hver gang du vil sjekke inn noe. (Ikke at det er noe galt i å bruke server, men det bør ikke gå på bekostning av muligheten til å jobbe lokalt.)

 

Hva vil du si er forskjellen mellom Mercurial og Git? Det virker som om begge er populære.

Begge er distribuerte, slik at du kan jobbe lokalt (men du kan selvsagt bruke server også). De er stort sett jevnbyrdige. Mercurial har et enklere kommandogrensesnitt, særlig dersom du er vant med Subversion. Git er litt bedre på branching.

 

Når det gjelder Windows-støtte, er Mercurial best, men Git kommer seg. Som du ser bruker jeg Git på Windows og er storfornøyd med det.

 

Forskjellene er med andre ord marginale. Det er ikke uten grunn at nettstedene GitHub (Git) og BitBucket (Mercurial) er så like som de er. Hvis du er nybegynner, anbefaler jeg Mercurial; hvis du vil bruke Git, vet du selv hvorfor.

 

Det er heller ingen krise hvis du siden ombestemmer deg: Både Git og Mercurial har innebygde verktøy for å importere repositories fra hverandre og andre systemer.

Endret 3. januar 2012 av ....

[Torbjørn T.]

 

Takk for et kjempebra og langt svar. Jeg har arbeidet med å lage strukturformlene videre idag utfra samme eksempel. Resultatet ble slik:

lengden på alle pinnene går ut fra en variabel jeg har kalt \storleik.

Redigert 2:

pgfmanual.pdf er forøvrig eit veldig nyttig dokument å ha om ein skal bruke PGF/Tikz. Veldig mykje informasjon, og mange døme.

 

Nokon feil er det dessverre. I starten er det fire guider som tek for seg konstruksjonen av fire ulike figurar frå starten av. I den andre av desse («A Petri-Net for Hagen», kapittel 3) er det eit avsnitt (avsnitt 3.8) som omhandlar relativ plassering av noder, slik eg har gjort over. Feilen her er at det står ein må bruke placements-biblioteket, medan det eigentleg er positioning-biblioteket som er aktuelt, jfr. dømet mitt over.

 

Og berre for ordens skuld legg eg inn link til Texample.com ein gong til:

http://www.texample.net/tikz/examples/

 

Når eg laga dømet brukte eg fyrst pgfmanual.pdf, men då fekk eg det naturleg nok ikkje til å fungere, sidan placements-biblioteket ikkje eksisterer ein gong. So då såg eg på eit døme under «node positioning» på Texample, og fann raskt at det var positioning-biblioteket eg måtte ha.

 

Det kan vere placements er gamalt, frå ein eldre versjon av Tikz, og so har ikkje manualen vorte oppdatert heilt, men det veit eg ikkje.

 

 

Blir TikZ forandret veldig etter hver oppdatering, så dokumenter man skrev for en god tid tilbake, ikke lengre kan kompileres fordi koden er "gammel"? Eller var det fordi du måtte friske litt opp her i sted?

Eg har ærleg talt ikkje peiling, og eg veit strengt tatt ikkje om andre feil i den bruksanvisninga (som eg kjem på no iallfall).

 

Grunnen til at eg nemnte det var at eg måtte repetere korleis ein gjorde akkurat det der, med relativ posisjonering av noder, so då fann eg nemnte feil. Tenkte det var greit å nemne det, i tilfelle du kom til å lese den for å eventuelt lære meir om emnet.

 

Texample ser ut til å være en flott side. rna-cordons-table så litt overveldende ut. Vet ikke helt hvor jeg skal begynne. Må man ha noe forhåndskunnskaper (annet enn å se i manualen)? Jeg kjenner litt til hvordan man trekker streker, slår sirkler og lignende enkle geometriske objekter i ActionScript (Adobe Flash).

Eg har lært meg Tikz hovudsakleg ved å bruke det, sjå i manualen, og leite etter løysingar på nettet om eg ikkje finn løysing der. ActionScript har eg aldri vore borti.

 

Skreiv litt om RNA-dømet, som ligg i spoiler under. Veit dog ikkje kor fornuftig det er eigentleg, det som står der.

 

Uansett, Tikz har ein ganske enkel og lettforståeleg syntaks tykkjer eg. Klart det krev litt arbeid spesielt i byrjinga, eg har brukt mykje tid på å bla i manualen for å finne ut korleis eg gjer noko, men det er ikkje spesielt vanskeleg.

 

 

 

 

Figuren er delt inn ved hjelp av scope-omgivnaden. Eit scope lar deg t.d leggje til ein parameter som farge, og denne vil gjelde for alle element inni omgivnaden. Til dømes for å farge ei linje raud, i staden for svart som er standard, vil ein skrive

\draw [red] (0,0) -- (3,0);

Skulle du lage mange linjer med same farge, kan du i staden for å leggje til [red] i kvar linje skrive slik.

\begin{scope}[red]
\draw (0,0) -- (3,0);
\draw (0,0) -- (2,2);
  .
  .
  .
\draw (1,0) -- (5,2);
\end{scope}

Alle linjene innanfor vert då raude.

 

So attende til RNA-dømet. Det fyrste som skjer i biletet er at ein del stilar vert definert. Ein kan lage ein stil, gje den eit namn, og bruke den på eit element ved å skrive berre namnet på stilen, i staden for ei liste med parameter.

 

Dette er ein stor fordel om ein skal lage fleire ting som skal ha same utsjånad, det vere linjer, sirklar eller anna. Skal ein t.d ha mange piler som er blå, med ein annan type pilspiss, og teikna med tjukk strek, kan ein i staden for å leggje dei same tre parametera til alle pilene, lage ein stil for dette. Det gjer det òg veldig enkelt å endre utsjånaden, for du treng berre endre den ein stad.

 

Stilene her gjer hovudsakleg linjene noko kortare, etter kor mange bokstavar som er i noden. Om du ser nøye etter, vil du sjå at streken fram til t.d NH₂ er kortare enn den fram til O. Unnataket er den fyrste stilen, som seier noko om kor mykje plass det skal vere rundt nodane (alle stader med tekst). every node gjer at dette vert brukt på alle nodane.

 

So kjem ein til sjølve figuren. Det fyrste scope-et lager tabellen i midten. Skal ikkje gå inn i detalj på den.

 

Etter den kjem eit scope for kvar struktur. Den fyrste av desse ser slik ut:

\begin{scope}[scale=0.5]	% Lysine
\draw[ultra thick,shorten >=2pt,shorten <=2pt] (90:8.2)
			arc(90:90-2*5.625:8.2);
\path (90-0.8*5.625:14.3) node (zero) {};
\draw[to_2]  (zero.center)	-- ++(30:1) node (CO) {}  
			-- +(330:1) node [anchor=base] {O$^{\mbox{-}}$};
\draw[to_1]  (CO.center) 	-- +(90:1) node (Od) {O};
\draw[to_1i] (CO.30)		-- +(90:1);
\draw[to_3]  (zero.center)	-- ++(150:1) node {NH$_{\mbox{3}}^{\mbox{+}}$};
\draw[to_3]  (zero.center)	-- ++(270:1) node(Cb){}
			-- ++(330:1) node (Cc) {}
			-- ++(270:1) node (Cd) {}
			-- ++(210:1) node (Ce) {}
			-- ++(150:1) node (Cf) {NH$_{\mbox{2}}$};
\end{scope}

scale-parameteren du ser i fyrste linje gjer akkurat det ein trur, den skalerer alle storleikar innanfor omgivnaden til halvparten. Neste linje er ikkje relatert til sjølve strukturen, den teikner den tjukke svarte streken utanfor tabellen.

 

Ved \path byrjer sjølve strukturen. Det som vert gjort i denne linja er å definere eit startpunkt. Kva som ligg til grunn for reknestykket i parentesen har eg ikkje satt meg inn i, men det er ikkje viktig her. Merk at startpunktet har fått namnet zero.

 

Linjene som byrjer med \draw gjer sjølve teikninga, og det vert nytta polarkoordinatar og relative posisjonar, for å gjere ting enklare. Ser nærare på fyrste element:

\draw[to_2]  (zero.center)	-- ++(30:1) node (CO) {}
			-- +(330:1) node [anchor=base] {O$^{\mbox{-}}$};

Her bruker ein stilen to_2, som vart definert i byrjinga. Fyrste strek byrjer i midten av noden ved namn zero, dermed zero.center. Sluttpunktet står etter --, og er her 1 lengdeeining borte, i retningen 30°. (0° er vassrett mot høgre.) I sluttpunktet er ein node ved namn CO, som ikkje har noko tekst, krøllparentesane er tomme.

 

++ framfor koordinatane gjer òg at dette vert det nye startpunktet. Det gjer at når neste strek vert teikna, starter den her, og den går i retning 330°, 1 lengdeeining. I sluttpunktet er ein node utan namn, men med teksten O^-. Slik held det fram.

 

[Rusma]

@longwinded: Jeg kjenner ikke så godt til verken svn, hg, git eller cvs, så jeg kan vel ikke si noe om det med server eller ikke server.

Har ikke så stor harddisk. Er det sånn at versjonskontrollene tar forholdsvis liten plass?

[Rusma]

 

Takk for et kjempebra og langt svar. Jeg har arbeidet med å lage strukturformlene videre idag utfra samme eksempel. Resultatet ble slik:

lengden på alle pinnene går ut fra en variabel jeg har kalt \storleik.

Redigert 2:

pgfmanual.pdf er forøvrig eit veldig nyttig dokument å ha om ein skal bruke PGF/Tikz. Veldig mykje informasjon, og mange døme.

 

Nokon feil er det dessverre. I starten er det fire guider som tek for seg konstruksjonen av fire ulike figurar frå starten av. I den andre av desse («A Petri-Net for Hagen», kapittel 3) er det eit avsnitt (avsnitt 3.8) som omhandlar relativ plassering av noder, slik eg har gjort over. Feilen her er at det står ein må bruke placements-biblioteket, medan det eigentleg er positioning-biblioteket som er aktuelt, jfr. dømet mitt over.

 

Og berre for ordens skuld legg eg inn link til Texample.com ein gong til:

http://www.texample.net/tikz/examples/

 

Når eg laga dømet brukte eg fyrst pgfmanual.pdf, men då fekk eg det naturleg nok ikkje til å fungere, sidan placements-biblioteket ikkje eksisterer ein gong. So då såg eg på eit døme under «node positioning» på Texample, og fann raskt at det var positioning-biblioteket eg måtte ha.

 

Det kan vere placements er gamalt, frå ein eldre versjon av Tikz, og so har ikkje manualen vorte oppdatert heilt, men det veit eg ikkje.

 

 

Blir TikZ forandret veldig etter hver oppdatering, så dokumenter man skrev for en god tid tilbake, ikke lengre kan kompileres fordi koden er "gammel"? Eller var det fordi du måtte friske litt opp her i sted?

Eg har ærleg talt ikkje peiling, og eg veit strengt tatt ikkje om andre feil i den bruksanvisninga (som eg kjem på no iallfall).

 

Grunnen til at eg nemnte det var at eg måtte repetere korleis ein gjorde akkurat det der, med relativ posisjonering av noder, so då fann eg nemnte feil. Tenkte det var greit å nemne det, i tilfelle du kom til å lese den for å eventuelt lære meir om emnet.

 

Texample ser ut til å være en flott side. rna-cordons-table så litt overveldende ut. Vet ikke helt hvor jeg skal begynne. Må man ha noe forhåndskunnskaper (annet enn å se i manualen)? Jeg kjenner litt til hvordan man trekker streker, slår sirkler og lignende enkle geometriske objekter i ActionScript (Adobe Flash).

Eg har lært meg Tikz hovudsakleg ved å bruke det, sjå i manualen, og leite etter løysingar på nettet om eg ikkje finn løysing der. ActionScript har eg aldri vore borti.

 

Skreiv litt om RNA-dømet, som ligg i spoiler under. Veit dog ikkje kor fornuftig det er eigentleg, det som står der.

 

Uansett, Tikz har ein ganske enkel og lettforståeleg syntaks tykkjer eg. Klart det krev litt arbeid spesielt i byrjinga, eg har brukt mykje tid på å bla i manualen for å finne ut korleis eg gjer noko, men det er ikkje spesielt vanskeleg.

 

 

 

 

Figuren er delt inn ved hjelp av scope-omgivnaden. Eit scope lar deg t.d leggje til ein parameter som farge, og denne vil gjelde for alle element inni omgivnaden. Til dømes for å farge ei linje raud, i staden for svart som er standard, vil ein skrive

\draw [red] (0,0) -- (3,0);

Skulle du lage mange linjer med same farge, kan du i staden for å leggje til [red] i kvar linje skrive slik.

\begin{scope}[red]
\draw (0,0) -- (3,0);
\draw (0,0) -- (2,2);
  .
  .
  .
\draw (1,0) -- (5,2);
\end{scope}

Alle linjene innanfor vert då raude.

 

So attende til RNA-dømet. Det fyrste som skjer i biletet er at ein del stilar vert definert. Ein kan lage ein stil, gje den eit namn, og bruke den på eit element ved å skrive berre namnet på stilen, i staden for ei liste med parameter.

 

Dette er ein stor fordel om ein skal lage fleire ting som skal ha same utsjånad, det vere linjer, sirklar eller anna. Skal ein t.d ha mange piler som er blå, med ein annan type pilspiss, og teikna med tjukk strek, kan ein i staden for å leggje dei same tre parametera til alle pilene, lage ein stil for dette. Det gjer det òg veldig enkelt å endre utsjånaden, for du treng berre endre den ein stad.

 

Stilene her gjer hovudsakleg linjene noko kortare, etter kor mange bokstavar som er i noden. Om du ser nøye etter, vil du sjå at streken fram til t.d NH₂ er kortare enn den fram til O. Unnataket er den fyrste stilen, som seier noko om kor mykje plass det skal vere rundt nodane (alle stader med tekst). every node gjer at dette vert brukt på alle nodane.

 

So kjem ein til sjølve figuren. Det fyrste scope-et lager tabellen i midten. Skal ikkje gå inn i detalj på den.

 

Etter den kjem eit scope for kvar struktur. Den fyrste av desse ser slik ut:

\begin{scope}[scale=0.5]	% Lysine
\draw[ultra thick,shorten >=2pt,shorten <=2pt] (90:8.2)
			arc(90:90-2*5.625:8.2);
\path (90-0.8*5.625:14.3) node (zero) {};
\draw[to_2]  (zero.center)	-- ++(30:1) node (CO) {}  
			-- +(330:1) node [anchor=base] {O$^{\mbox{-}}$};
\draw[to_1]  (CO.center) 	-- +(90:1) node (Od) {O};
\draw[to_1i] (CO.30)		-- +(90:1);
\draw[to_3]  (zero.center)	-- ++(150:1) node {NH$_{\mbox{3}}^{\mbox{+}}$};
\draw[to_3]  (zero.center)	-- ++(270:1) node(Cb){}
			-- ++(330:1) node (Cc) {}
			-- ++(270:1) node (Cd) {}
			-- ++(210:1) node (Ce) {}
			-- ++(150:1) node (Cf) {NH$_{\mbox{2}}$};
\end{scope}

scale-parameteren du ser i fyrste linje gjer akkurat det ein trur, den skalerer alle storleikar innanfor omgivnaden til halvparten. Neste linje er ikkje relatert til sjølve strukturen, den teikner den tjukke svarte streken utanfor tabellen.

 

Ved \path byrjer sjølve strukturen. Det som vert gjort i denne linja er å definere eit startpunkt. Kva som ligg til grunn for reknestykket i parentesen har eg ikkje satt meg inn i, men det er ikkje viktig her. Merk at startpunktet har fått namnet zero.

 

Linjene som byrjer med \draw gjer sjølve teikninga, og det vert nytta polarkoordinatar og relative posisjonar, for å gjere ting enklare. Ser nærare på fyrste element:

\draw[to_2]  (zero.center)	-- ++(30:1) node (CO) {}
			-- +(330:1) node [anchor=base] {O$^{\mbox{-}}$};

Her bruker ein stilen to_2, som vart definert i byrjinga. Fyrste strek byrjer i midten av noden ved namn zero, dermed zero.center. Sluttpunktet står etter --, og er her 1 lengdeeining borte, i retningen 30°. (0° er vassrett mot høgre.) I sluttpunktet er ein node ved namn CO, som ikkje har noko tekst, krøllparentesane er tomme.

 

++ framfor koordinatane gjer òg at dette vert det nye startpunktet. Det gjer at når neste strek vert teikna, starter den her, og den går i retning 330°, 1 lengdeeining. I sluttpunktet er ein node utan namn, men med teksten O^-. Slik held det fram.

 

 

Takker for enda et fyldig og godt svar. Hadde all kode vært så godt dokumenter tror jeg verden hadde vært et bedre sted å leve

[....]

Jeg kjenner ikke så godt til verken svn, hg, git eller cvs, så jeg kan vel ikke si noe om det med server eller ikke server.

Sentralisert betyr at all versjonshistorikken befinner seg på serveren, som du må koble deg til for å sjekke inn endringene dine. Med et distribuert system, derimot, har du versjonshistorikken lokalt på din egen harddisk og på serveren: Du har et «server-repo» og et lokalt repo, og det siste er i utgangspunktet en kopi (klon) av det første. Når du jobber på det lokale repo’et, divergerer det fra server-repoet, inntil du synkroniserer de to repo’ene ved å laste opp dine nye endringer til serveren.

 

Historisk sett er CVS det eldste systemet, og er sentralisert. Så kom Subversion (SVN), en forbedring av CVS, men fortsatt sentralisert. Git og Mercurial (hg) er relativt nye, oppsto samtidig, og er distribuerte. Mercurial minner mye om Subversion, mens Git har sin egen terminologi.

 

Lager du deg en konto på GitHub eller BitBucket, har du server. Dette er ypperlig for å dele arbeid med andre (men du kan også ha private repo’er der du foretrekker det). GitHub/BitBucket er i utgangspunktet sosialt: Hvis du gir andre tilgang til repo’et ditt, kan de laste det ned til egen maskin og gjøre sine egne endringer, som de siden kan dele med deg. Du avgjør om du vil inkludere dem i det offentlige repo’et eller ikke, og du kan velge ut akkurat de endringene du vil ha. Alternativt kan du opprette en prosjektgruppe og gi alle i gruppen skrivetilgang til serveren, og da fungerer det som SVN (men med fordelene med lokal versjonshistorikk).

 

Med andre ord: ypperlig for grupperapporter.

 

Har ikke så stor harddisk. Er det sånn at versjonskontrollene tar forholdsvis liten plass?

Ja. Det er typisk bare deltaene (forskjellene fra versjon til versjon) som lagres.

Endret 3. januar 2012 av ....

[Rusma]

Har ikke så stor harddisk. Er det sånn at versjonskontrollene tar forholdsvis liten plass?

Ja. Det er typisk bare deltaene (forskjellene fra versjon til versjon) som lagres.

 

Kult.

 

Jeg liker det der med å kopiere bare deltaer. Det sparer jo også mange overføringsbytes (hvis det da går via nettet), og tid. rsync er et genialt program i så måte (hvis man kopierer kjempefiler).

[....]

La meg bare si det slik: Versjonskontroll brukes av millioner av programmerere verden over for å samarbeide om kildekode, og hvis ikke programmererne får gjort jobben sin, får ingen andre gjort noe heller. Så vi snakker om det mest velutprøvde og robuste systemet som noensinne er utviklet for lagring og organisering av data.

 

Både Git og Mercurial beregner SHA-1-sjekksummen av hver versjon (bedre enn CRC og MD5). Svikter harddisken eller minnet i det stille mens du jobber, vil versjonssystemet oppdage det. Det gjør også backup tryggere, siden du kan verifisere at filene er intakte.

Endret 3. januar 2012 av ....

[Euklid]

Takk for en veldig god beskrivelse, longwinded. Å sette opp Git på Macen min gikk som en lek. Nå må jeg bare tenke ut en egnet synkroniseringsløsning mot Dropbox (bruker en del forskjellige maskiner ...).

 

En enkel sak: konvensjonen er visstnok at linespread 1.3 er ekvivalent med halvannen linjeavstand, mens 1.6 gir dobbel. For det første, stemmer dette? For det andre, vet noen av dere hva logikken er? Skal sette opp et dokument med lineavstand som skal tilsvare 1.5 i Word, nemlig.

 

(Bruker 12pt Computer Modern.)