Thread: [Vim-latex-devel] Able to do compilation in a sub-directory?
Brought to you by:
srinathava,
tmaas
Menu
▾
▴
vim-latex-devel
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-14 06:28:12
|
Hi, I'm coming from a texlipse (Eclipse plug-in) background. Been through the Latex-Suite Reference, but could not find this particular 'feature'. Would it be possible to do a compile in a specific subdirectory (by default ./tmp in texlipse). This helps prevent clutter in the main directory. I've not checked, but I believe texlipse does this using the --output-directory option of tex/pdflatex. Would changing g:Tex_CompileRule_* allow me to have this behaviour (all the temporary files like aux,bbl,blg,log,out,toc in ./tmp but the final output dvi/pdf in ./)? |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-15 12:04:32
|
On Mon, 2011-02-14 at 14:27 +0800, Ng Oon-Ee wrote: > Hi, > > I'm coming from a texlipse (Eclipse plug-in) background. Been through > the Latex-Suite Reference, but could not find this particular 'feature'. > > Would it be possible to do a compile in a specific subdirectory (by > default ./tmp in texlipse). This helps prevent clutter in the main > directory. > > I've not checked, but I believe texlipse does this using the > --output-directory option of tex/pdflatex. Would changing > g:Tex_CompileRule_* allow me to have this behaviour (all the temporary > files like aux,bbl,blg,log,out,toc in ./tmp but the final output dvi/pdf > in ./)? > I take it this is not possible, then? |
|
From: Mike R. <ri...@um...> - 2011-02-15 17:34:56
|
On Tue, Feb 15, 2011 at 7:04 AM, Ng Oon-Ee <ng...@gm...> wrote: > On Mon, 2011-02-14 at 14:27 +0800, Ng Oon-Ee wrote: >> Hi, >> >> I'm coming from a texlipse (Eclipse plug-in) background. Been through >> the Latex-Suite Reference, but could not find this particular 'feature'. >> >> Would it be possible to do a compile in a specific subdirectory (by >> default ./tmp in texlipse). This helps prevent clutter in the main >> directory. >> >> I've not checked, but I believe texlipse does this using the >> --output-directory option of tex/pdflatex. Would changing >> g:Tex_CompileRule_* allow me to have this behaviour (all the temporary >> files like aux,bbl,blg,log,out,toc in ./tmp but the final output dvi/pdf >> in ./)? >> > > I take it this is not possible, then? In principle, if you can determine the commands used to make it happen in the shell, then you can get vim-latex to do it for you as well. I've never tried compiling in a subdir, though. Let us know if you can manage to do it at the command line. -Mike Richman > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Vim-latex-devel mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vim-latex-devel > |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 01:01:40
|
On Tue, 2011-02-15 at 12:34 -0500, Mike Richman wrote: > On Tue, Feb 15, 2011 at 7:04 AM, Ng Oon-Ee <ng...@gm...> wrote: > > On Mon, 2011-02-14 at 14:27 +0800, Ng Oon-Ee wrote: > >> Hi, > >> > >> I'm coming from a texlipse (Eclipse plug-in) background. Been through > >> the Latex-Suite Reference, but could not find this particular 'feature'. > >> > >> Would it be possible to do a compile in a specific subdirectory (by > >> default ./tmp in texlipse). This helps prevent clutter in the main > >> directory. > >> > >> I've not checked, but I believe texlipse does this using the > >> --output-directory option of tex/pdflatex. Would changing > >> g:Tex_CompileRule_* allow me to have this behaviour (all the temporary > >> files like aux,bbl,blg,log,out,toc in ./tmp but the final output dvi/pdf > >> in ./)? > >> > > > > I take it this is not possible, then? > > In principle, if you can determine the commands used to make it happen > in the shell, then you can get vim-latex to do it for you as well. > I've never tried compiling in a subdir, though. > > Let us know if you can manage to do it at the command line. > > -Mike Richman Hmm, from checking more closely, it seems all texlipse does is move the temp files out of the compilation folder after a completed (or partially completed) compile. No point if its done that way then. I was thinking more along the lines of how programs can be compiled in a clean build directory, but perhaps that'd be a bit complicated/unnecessary in this situation. >From a bit of testing its obviously possible to do all output to a tmp directory. pdflatex -output-directory ./tmp foo.tex The output file (foo.pdf) would also appear there, which is where the lack of a -output-filename hampers things (if such would exist, we could just specify the filename to be something like ../foo) |
|
From: Ted P. <te...@te...> - 2011-02-16 02:22:31
|
> pdflatex -output-directory ./tmp foo.tex > > The output file (foo.pdf) would also appear there, which is where the > lack of a -output-filename hampers things (if such would exist, we could > just specify the filename to be something like ../foo) You can always supplement with symlinks. For example, just once: ln -sf tmp/foo.pdf Then anytime after that: pdflatex -output-director ./tmp foo.tex Suddenly a "foo.pdf" will get placed within the current directory, and it should get updated every time you run pdflatex again. --Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 02:40:58
|
On Tue, 2011-02-15 at 21:22 -0500, Ted Pavlic wrote: > > pdflatex -output-directory ./tmp foo.tex > > > > The output file (foo.pdf) would also appear there, which is where the > > lack of a -output-filename hampers things (if such would exist, we could > > just specify the filename to be something like ../foo) > > You can always supplement with symlinks. For example, just once: > > ln -sf tmp/foo.pdf > > Then anytime after that: > > pdflatex -output-director ./tmp foo.tex > > Suddenly a "foo.pdf" will get placed within the current directory, and > it should get updated every time you run pdflatex again. > > --Ted > Yes, I did think of that, but the symlink will always exist even if the file does not =). Its plenty good enough though, so that's probably what I'll use going forward. Now to figure out whether this affects include paths etc. |
|
From: Ted P. <te...@te...> - 2011-02-16 03:02:42
|
>> ln -sf tmp/foo.pdf > Yes, I did think of that, but the symlink will always exist even if the > file does not =). Its plenty good enough though, so that's probably what > I'll use going forward. Well, if you plan on keeping that tmp directory around for more than a few builds, the symlink: cd tmp ln -sf ../foo.pdf works just as well, but the "foo.pdf" that shows up in your main directory isn't a symlink. Maybe that's a better fit? --Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 03:10:43
|
On Tue, 2011-02-15 at 22:02 -0500, Ted Pavlic wrote: > >> ln -sf tmp/foo.pdf > > Yes, I did think of that, but the symlink will always exist even if the > > file does not =). Its plenty good enough though, so that's probably what > > I'll use going forward. > > Well, if you plan on keeping that tmp directory around for more than a > few builds, the symlink: > > cd tmp > ln -sf ../foo.pdf > > works just as well, but the "foo.pdf" that shows up in your main > directory isn't a symlink. Maybe that's a better fit? > > --Ted > If it stays around a while, both ways work =). I suppose it WOULD stay around a while though, so not a big deal. *tangentially, I recall with some other apps I tried they would overwrite symlinks, I guess its to do with how they access the file?* |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 03:53:39
|
On Wed, 2011-02-16 at 11:10 +0800, Ng Oon-Ee wrote: > On Tue, 2011-02-15 at 22:02 -0500, Ted Pavlic wrote: > > >> ln -sf tmp/foo.pdf > > > Yes, I did think of that, but the symlink will always exist even if the > > > file does not =). Its plenty good enough though, so that's probably what > > > I'll use going forward. > > > > Well, if you plan on keeping that tmp directory around for more than a > > few builds, the symlink: > > > > cd tmp > > ln -sf ../foo.pdf > > > > works just as well, but the "foo.pdf" that shows up in your main > > directory isn't a symlink. Maybe that's a better fit? > > > > --Ted > > > If it stays around a while, both ways work =). I suppose it WOULD stay > around a while though, so not a big deal. > > *tangentially, I recall with some other apps I tried they would > overwrite symlinks, I guess its to do with how they access the file?* > Testing this out, I notice that if I use -jobname, \lv will complain that a file is not found (foo.tex producing bar.dvi, of course \lv looks for foo.dvi). Can this be dealt with (changing the argument sent to g:Tex_ViewRule_dvi)? |
|
From: Ted P. <te...@te...> - 2011-02-16 04:12:42
|
> Testing this out, I notice that if I use -jobname, \lv will complain
> that a file is not found (foo.tex producing bar.dvi, of course \lv looks
> for foo.dvi). Can this be dealt with (changing the argument sent to
> g:Tex_ViewRule_dvi)?
I have a feeling you should look at:
g:Tex_ViewRuleComplete_dvi
which takes precedence over the normal ViewRule. It is exected "as-is"
(except for replacing any $*'s).
So you could set g:Tex_ViewRuleComplete_dvi for your particular project
to use the right jobname. Otherwise, it would be difficult for vim-latex
to figure out the right jobname.
(I guess someone(?) could add a feature that looks for "blah.jobname"
files that function similar to "blah.latexmain" but sets up the right
jobname instead...)
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 05:11:40
|
On Tue, 2011-02-15 at 23:28 -0500, Ted Pavlic wrote: > > So you could set g:Tex_ViewRuleComplete_dvi for your particular project > > to use the right jobname. Otherwise, it would be difficult for vim-latex > > to figure out the right jobname. > > Connecting this with the response I just sent, you can of course put > something like... > > :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > > inside your latexmain file. The latexmain files get sourced. If you > don't like the extra buffer that gets opened, then make sure the > latexmain file looks like "main.latexmain" as opposed to > "main.tex.latexmain". Both should get sourced though. > > --Ted > What would a 'view rule with jobname included' look like? My current view rule is simple 'okular', and I assume 'blah.dvi' is automatically appended. How do I change what is appended? Or should I simply put 'okular foo.dvi' where foo is the jobname? |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 05:17:03
|
On Wed, 2011-02-16 at 13:11 +0800, Ng Oon-Ee wrote: > On Tue, 2011-02-15 at 23:28 -0500, Ted Pavlic wrote: > > > So you could set g:Tex_ViewRuleComplete_dvi for your particular project > > > to use the right jobname. Otherwise, it would be difficult for vim-latex > > > to figure out the right jobname. > > > > Connecting this with the response I just sent, you can of course put > > something like... > > > > :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > > > > inside your latexmain file. The latexmain files get sourced. If you > > don't like the extra buffer that gets opened, then make sure the > > latexmain file looks like "main.latexmain" as opposed to > > "main.tex.latexmain". Both should get sourced though. > > > > --Ted > > > What would a 'view rule with jobname included' look like? > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > automatically appended. How do I change what is appended? Or should I > simply put 'okular foo.dvi' where foo is the jobname? > Oh, and while that would work for \lv, doesn't seem to be a corresponding function for \ls |
|
From: Ted P. <te...@te...> - 2011-02-16 06:24:03
|
>> My current view rule is simple 'okular', and I assume 'blah.dvi' is >> automatically appended. How do I change what is appended? Or should I >> simply put 'okular foo.dvi' where foo is the jobname? >> > Oh, and while that would work for \lv, doesn't seem to be a > corresponding function for \ls \ls looks at Viewer to try to determine if it knows of a way to pass the corresponding source special hook to the viewer. If a viewer doesn't know anything about source specials, then there's no hope. So an override for \ls like the override for \lv would have to have a way of passing in the line number to hookup with the source specials and possibly enough information to the editor to then reverse search back to the vim document after browsing. This is why I think the ultimate solution would be to build jobname support directly into compiler.vim (that would default to jobname=filename) so all of these little hacks wouldn't be needed. It shouldn't be hard to do... It would just require... (a) Determining how to pass the jobname in (via a variable? via another filename? both?) (b) Going through and using the jobname in compiler.vim whenever it is available (probably only 9 or 10 different places) If someone has a good idea for a patch, then git-format-patch/git-send-email them to the list for review and application. --Ted -- Ted Pavlic <te...@te...> |
|
From: Ted P. <te...@te...> - 2011-02-16 16:46:21
|
> If someone has a good idea for a patch, then > git-format-patch/git-send-email them to the list for review and > application. Of course, using the "Patches tracker" on the SF site is also a good alternative. https://sourceforge.net/tracker/?group_id=52322&atid=466458 Patches can be uploaded, commented on, and eventually accepted (and committed) through the web interface. I am a bigger fan of the old-fashioned mailing list interface (i.e., using 'git send-email' to post a message with "[PATCH]" in the subject to the mailing list where it can be publicly viewed and scrutinized and announced -- that's how the Git development team does it); however, SF has a history of doing these things through a tracked web interface. --Ted -- Ted Pavlic <te...@te...> |
|
From: Mike R. <ri...@um...> - 2011-02-21 16:50:20
|
Hi all,
I always sort of just took the auxiliary files for granted, but now I
like the idea of avoiding the clutter.
I compile all of my documents using latex -> dvips -> ps2pdf. Now I
adjusted my g:Tex_CompileRule_pdf so that it stores all the auxiliary
files in the .build/ subdirectory. It just copies the files out of
there to do the compile, and moves the new versions back into .build
afterwards. The subdir is created automatically.
Here's the relevant section in my ~/.vim/ftplugin/tex.vim:
let g:Tex_DefaultTargetFormat='pdf'
let g:Tex_MultipleCompileFormats='pdf'
let g:Tex_CompileRule_pdf='mkdir -p .build'
\.'&& cp .build/* .'
\.'; latex -interaction=nonstopmode -shell-escape $*.tex'
\.'&& dvips -P pdf -q $*.dvi'
\.'&& rm -f $*.dvi'
\.'&& ps2pdf $*.ps'
\.'&& rm -f $*.ps'
\.'&& mv *.aux *.bbl *.bl *.blg *.lof *.log *.lot *.nav *.out *.toc'
\.' .build/'
Hope someone finds this useful too :)
-Mike Richman
|
|
From: Ted P. <te...@te...> - 2011-02-16 04:01:14
|
> *tangentially, I recall with some other apps I tried they would
> overwrite symlinks, I guess its to do with how they access the file?*
Yep. Some apps will unlink (i.e., delete) the file and re-create it.
pdflatex does not do that; it overwrites whatever is there (and thus
follows the symlink). Among other things, that helps to ensure that
autorefreshing works in more PDF viewers.
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Aditya M. <ad...@um...> - 2011-02-16 04:16:04
|
On Tue, 15 Feb 2011, Ted Pavlic wrote: > (I guess someone(?) could add a feature that looks for "blah.jobname" > files that function similar to "blah.latexmain" but sets up the right > jobname instead...) Isn't it better to make blah.latexmain a configuration file, so that it may contain jobname=whatever output-directory=./tmp Aditya |
|
From: Ted P. <te...@te...> - 2011-02-16 04:26:32
|
> Isn't it better to make blah.latexmain a configuration file, so that it > may contain blah.latexmain is already a 'configuration file'. It gets :sourced whenenver it is found. So you could already put in it something like... let g:jobname=whatever and have each \l* command respond to g:jobname if found. So that's another way it could be done. --Ted -- Ted Pavlic <te...@te...> |
|
From: Ted P. <te...@te...> - 2011-02-16 04:32:26
|
> and have each \l* command respond to g:jobname if found. So that's
> another way it could be done.
I didn't mean to imply that the \l* commands already respond to such a
variable. They could be modified to respond to it though, and that
variable could be set within the .latexmain project file.
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Ted P. <te...@te...> - 2011-02-16 04:28:12
|
> So you could set g:Tex_ViewRuleComplete_dvi for your particular project
> to use the right jobname. Otherwise, it would be difficult for vim-latex
> to figure out the right jobname.
Connecting this with the response I just sent, you can of course put
something like...
:let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included'
inside your latexmain file. The latexmain files get sourced. If you
don't like the extra buffer that gets opened, then make sure the
latexmain file looks like "main.latexmain" as opposed to
"main.tex.latexmain". Both should get sourced though.
--Ted
--
Ted Pavlic <te...@te...>
Please visit my 2010 d'Feet ALS walk page:
http://web.alsa.org/goto/tpavlic
My family appreciates your support in the fight to defeat ALS.
|
|
From: Ted P. <te...@te...> - 2011-02-16 06:11:38
|
>> :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' >> >> inside your latexmain file. The latexmain files get sourced. If you > What would a 'view rule with jobname included' look like? > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > automatically appended. How do I change what is appended? Or should I > simply put 'okular foo.dvi' where foo is the jobname? Yes, okular foo.dvi would probably be what you would want. That way \lv executes it directly. Unfortunately, that will likely break Vim-LaTeX's ability to view temporary files generated by compiling fragments (i.e., temporary targets generated when using \ll while you have highlighted a block of LaTeX code). --Ted -- Ted Pavlic <te...@te...> |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-16 06:16:45
|
On Wed, 2011-02-16 at 01:11 -0500, Ted Pavlic wrote: > >> :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > >> > >> inside your latexmain file. The latexmain files get sourced. If you > > What would a 'view rule with jobname included' look like? > > > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > > automatically appended. How do I change what is appended? Or should I > > simply put 'okular foo.dvi' where foo is the jobname? > > Yes, > > okular foo.dvi > > would probably be what you would want. That way \lv executes it > directly. Unfortunately, that will likely break Vim-LaTeX's ability to > view temporary files generated by compiling fragments (i.e., temporary > targets generated when using \ll while you have highlighted a block of > LaTeX code). > > --Ted > Looks like its best just to skip 'jobname' entirely and simply rename the file myself for final submission =). Thanks Ted and the rest who have replied. |
|
From: Ng Oon-Ee <ng...@gm...> - 2011-02-17 08:58:23
|
On Wed, 2011-02-16 at 14:16 +0800, Ng Oon-Ee wrote: > On Wed, 2011-02-16 at 01:11 -0500, Ted Pavlic wrote: > > >> :let g:Tex_ViewRuleComplete_dvi='your view rule with jobname included' > > >> > > >> inside your latexmain file. The latexmain files get sourced. If you > > > What would a 'view rule with jobname included' look like? > > > > > > My current view rule is simple 'okular', and I assume 'blah.dvi' is > > > automatically appended. How do I change what is appended? Or should I > > > simply put 'okular foo.dvi' where foo is the jobname? > > > > Yes, > > > > okular foo.dvi > > > > would probably be what you would want. That way \lv executes it > > directly. Unfortunately, that will likely break Vim-LaTeX's ability to > > view temporary files generated by compiling fragments (i.e., temporary > > targets generated when using \ll while you have highlighted a block of > > LaTeX code). > > > > --Ted > > > Looks like its best just to skip 'jobname' entirely and simply rename > the file myself for final submission =). Thanks Ted and the rest who > have replied. > And as a final closure for this, nope this method won't work. vim-latex doesn't know where to find foo.aux for bibtex, so won't run it, and you won't get your bibliography. Quite a pity, really. Back to having all files in the root folder =). |
|
From: Ted P. <te...@te...> - 2011-02-21 17:19:07
|
Mike -- > I always sort of just took the auxiliary files for granted, but now I > like the idea of avoiding the clutter. That's valuable clutter though. There are BBL files in there to inspect/change; there are AUX files for other tools to use; etc. Not only that, having the AUX available allows for quicker edits later. Imagine you have a large book that takes a few seconds each pass... If you changed a single typo somewhere, you wouldn't want to run every pass again. So I guess one man's trash is... :) Having said that, the "jobname" option discussed earlier is a nice compromise. LaTeX still has the AUX files available tucked away out of sight, and so subsequent builds are efficient while the main working directory is relatively clean. > let g:Tex_DefaultTargetFormat='pdf' > let g:Tex_MultipleCompileFormats='pdf' > let g:Tex_CompileRule_pdf='mkdir -p .build' Does that solution still allow LaTeX to automatically run BibTeX and makeindex as needed? It seems like it would break BBL/index generation. <?> Because you're doing dvi->ps->pdf (as everyone should be (at least those who don't mind some of the (usually minor) issues with using transparency in EPS images)), it seems like there would be a better way. You can configure LaTeX to do the dvi,ps,pdf sequence for you, but you can add your cleanup stuff to the PDF rule. That way your AUX files stick around for Vim-LaTeX, and they disappear only at the very end when the final PDF is produced. Just a thought... --Ted -- Ted Pavlic <te...@te...> |
|
From: Mike R. <ri...@um...> - 2011-02-21 18:09:42
|
Hi Ted,
On Mon, Feb 21, 2011 at 12:18 PM, Ted Pavlic <te...@te...> wrote:
> Mike --
>
>> I always sort of just took the auxiliary files for granted, but now I
>> like the idea of avoiding the clutter.
>
> That's valuable clutter though. There are BBL files in there to
> inspect/change; there are AUX files for other tools to use; etc. Not
> only that, having the AUX available allows for quicker edits later.
> Imagine you have a large book that takes a few seconds each pass... If
> you changed a single typo somewhere, you wouldn't want to run every pass
> again. So I guess one man's trash is... :)
Are you saying you inspect these files by hand, regularly? I almost
never have, and I never change them manually. So keeping them around,
but out of sight, seems desirable.
>> let g:Tex_DefaultTargetFormat='pdf'
>> let g:Tex_MultipleCompileFormats='pdf'
>> let g:Tex_CompileRule_pdf='mkdir -p .build'
>
> Does that solution still allow LaTeX to automatically run BibTeX and
> makeindex as needed? It seems like it would break BBL/index generation. <?>
Good point, in fact it does break BibTeX et al.
>
> Because you're doing dvi->ps->pdf (as everyone should be (at least those
> who don't mind some of the (usually minor) issues with using
> transparency in EPS images)), it seems like there would be a better way.
> You can configure LaTeX to do the dvi,ps,pdf sequence for you, but you
> can add your cleanup stuff to the PDF rule. That way your AUX files
> stick around for Vim-LaTeX, and they disappear only at the very end when
> the final PDF is produced.
I've tried to configure this before, but had no luck. Based on
latex-suite.txt, I thought the following would do the trick:
let g:Tex_DefaultTargetFormat='pdf'
let g:Tex_MultipleCompileFormats='dvi,ps,pdf'
let g:Tex_FormatDependency_pdf='dvi,ps,pdf'
let g:Tex_CompileRule_dvi='mkdir -p .build && cp .build/* . ;'
\.'latex -interaction=nonstopmode -shell-escape $*.tex'
let g:Tex_CompileRule_ps='dvips -P pdf -q $*.dvi && rm -f $*.dvi'
let g:Tex_CompileRule_pdf='ps2pdf $*.ps'
\.'&& rm -f $*.ps'
\.'&& mv *.aux *.bbl *.bl *.blg *.lof *.log *.lot *.nav *.out '
\.' *.snm *.toc .build/'
But when I set it this way, it just compiles the dvi file and then
stops. What am I missing?
>
> Just a thought...
> --Ted
>
> --
> Ted Pavlic <te...@te...>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Vim-latex-devel mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vim-latex-devel
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X