Thread: [CEDET-devel] find-file-noselect, flymake and others
Brought to you by:
zappo
From: Vladimir K. <vka...@in...> - 2012-12-10 14:22:46
|
Hi, everyone! Three issues today :-) Issue N1. While waiting for CEDET to parse my imports (Java, but in this particular case it does not matter) I've noticed that emacs launches a flymake subprocess for each and every of them, which gives my laptop a hard time. I made a simple check: $ rgrep find-file-noselect * | wc -l 128 Not all of those are wrong, of course, but some definitely are. There's got to be a better way to do background parsing, as find-file-hook is a popular way to add extra functionality. Is there a better way to 1) open a file 2) extract/cache tags 3) close the file? Issue N2. Recent changes introduced an new error during load time: "Symbol's function definition is void: ede-java-root-project". After init the project can be evaluated as always. As much as I can see I am not the only one suffering from this bug. Issue N3. This one's easy. I believe that not all jar files supply javap with source file info, thus, javap parser has to check whether it should skip the first string ("Compiled from...") in program's output. Can somebody fix it? PS Still waiting for my papers. FSF clerk did not even answer my last letter. -- Yours sincerely, Vladimir Kazanov, software developer, mob. +7 (963) 304-05-12 ICQ: 82042707 skype: stvovka email: vka...@in... -- С уважением, Владимир Казанов, программист, моб. +7 (963) 304-05-12 ICQ 82042707 skype: stvovka эл.почта vka...@in... |
From: Alex O. <al...@gm...> - 2012-12-10 15:57:54
|
Hi I believe, that issue N2 should be fixed with commit that i did right now - I added autoloads for class definitions. I can look to issue N3 - maybe you know which jar files produced such behaviour? On Mon, Dec 10, 2012 at 3:22 PM, Vladimir Kazanov <vka...@in...> wrote: > Hi, everyone! > > Three issues today :-) > > Issue N1. > > While waiting for CEDET to parse my imports (Java, but in this particular > case it does not matter) I've noticed that emacs launches a flymake > subprocess for each and every of them, which gives my laptop a hard time. I > made a simple check: > > $ rgrep find-file-noselect * | wc -l > 128 > > Not all of those are wrong, of course, but some definitely are. There's got > to be a better way to do background parsing, as find-file-hook is a popular > way to add extra functionality. Is there a better way to 1) open a file 2) > extract/cache tags 3) close the file? > > Issue N2. > > Recent changes introduced an new error during load time: "Symbol's function > definition is void: ede-java-root-project". After init the project can be > evaluated as always. As much as I can see I am not the only one suffering > from this bug. > > Issue N3. > > This one's easy. I believe that not all jar files supply javap with source > file info, thus, javap parser has to check whether it should skip the first > string ("Compiled from...") in program's output. Can somebody fix it? > > PS Still waiting for my papers. FSF clerk did not even answer my last > letter. > > > > -- > Yours sincerely, > > Vladimir Kazanov, > software developer, > mob. +7 (963) 304-05-12 > ICQ: 82042707 > skype: stvovka > email: vka...@in... > -- > > С уважением, > > Владимир Казанов, > программист, > моб. +7 (963) 304-05-12 > ICQ 82042707 > skype: stvovka > эл.почта vka...@in... > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > -- With best wishes, Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: Tomasz G. <to...@wp...> - 2012-12-10 19:26:46
|
Alex Ott <al...@gm...> writes: > I believe, that issue N2 should be fixed with commit that i did right > now - I added autoloads for class definitions. I can also confirm it is fixed now. Thanks. Regards Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2012-12-11 02:25:03
|
Hi Alex, Hopefully David can confirm, but I think that upon integration with Emacs all #autoload cookies on classes had to be removed. I'm not sure what I did that broke the current scheme, as things 'worked for me' when I was done. The EDE autoloader (in ede/auto.el) is supposed to recognize the class, and load them if needed, but that doesn't work if someone sticks the class directly into their .emacs file. In theory, you would need a: (require 'ede/cpp-root) in front of all project declarations. Maybe these two project types are an ok thing to autoload. Eric On 12/10/2012 10:57 AM, Alex Ott wrote: > Hi > > I believe, that issue N2 should be fixed with commit that i did right > now - I added autoloads for class definitions. > > I can look to issue N3 - maybe you know which jar files produced such behaviour? > > On Mon, Dec 10, 2012 at 3:22 PM, Vladimir Kazanov<vka...@in...> wrote: >> Hi, everyone! >> >> Three issues today :-) >> >> Issue N1. >> >> While waiting for CEDET to parse my imports (Java, but in this particular >> case it does not matter) I've noticed that emacs launches a flymake >> subprocess for each and every of them, which gives my laptop a hard time. I >> made a simple check: >> >> $ rgrep find-file-noselect * | wc -l >> 128 >> >> Not all of those are wrong, of course, but some definitely are. There's got >> to be a better way to do background parsing, as find-file-hook is a popular >> way to add extra functionality. Is there a better way to 1) open a file 2) >> extract/cache tags 3) close the file? >> >> Issue N2. >> >> Recent changes introduced an new error during load time: "Symbol's function >> definition is void: ede-java-root-project". After init the project can be >> evaluated as always. As much as I can see I am not the only one suffering >> from this bug. >> >> Issue N3. >> >> This one's easy. I believe that not all jar files supply javap with source >> file info, thus, javap parser has to check whether it should skip the first >> string ("Compiled from...") in program's output. Can somebody fix it? >> >> PS Still waiting for my papers. FSF clerk did not even answer my last >> letter. >> >> >> >> -- >> Yours sincerely, >> >> Vladimir Kazanov, >> software developer, >> mob. +7 (963) 304-05-12 >> ICQ: 82042707 >> skype: stvovka >> email: vka...@in... >> -- >> >> С уважением, >> >> Владимир Казанов, >> программист, >> моб. +7 (963) 304-05-12 >> ICQ 82042707 >> skype: stvovka >> эл.почта vka...@in... >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> Cedet-devel mailing list >> Ced...@li... >> https://lists.sourceforge.net/lists/listinfo/cedet-devel >> > > > |
From: Alex O. <al...@gm...> - 2012-12-11 10:09:56
|
Thank you Eric Do we have documented this anywhere? It would be nice, to have special page for developers for such things... On Tue, Dec 11, 2012 at 3:24 AM, Eric M. Ludlam <er...@si...> wrote: > Hi Alex, > > Hopefully David can confirm, but I think that upon integration with > Emacs all #autoload cookies on classes had to be removed. I'm not sure > what I did that broke the current scheme, as things 'worked for me' when > I was done. > > The EDE autoloader (in ede/auto.el) is supposed to recognize the class, > and load them if needed, but that doesn't work if someone sticks the > class directly into their .emacs file. > > In theory, you would need a: > > (require 'ede/cpp-root) > > in front of all project declarations. > > Maybe these two project types are an ok thing to autoload. > > Eric > > On 12/10/2012 10:57 AM, Alex Ott wrote: >> Hi >> >> I believe, that issue N2 should be fixed with commit that i did right >> now - I added autoloads for class definitions. >> >> I can look to issue N3 - maybe you know which jar files produced such behaviour? >> >> On Mon, Dec 10, 2012 at 3:22 PM, Vladimir Kazanov<vka...@in...> wrote: >>> Hi, everyone! >>> >>> Three issues today :-) >>> >>> Issue N1. >>> >>> While waiting for CEDET to parse my imports (Java, but in this particular >>> case it does not matter) I've noticed that emacs launches a flymake >>> subprocess for each and every of them, which gives my laptop a hard time. I >>> made a simple check: >>> >>> $ rgrep find-file-noselect * | wc -l >>> 128 >>> >>> Not all of those are wrong, of course, but some definitely are. There's got >>> to be a better way to do background parsing, as find-file-hook is a popular >>> way to add extra functionality. Is there a better way to 1) open a file 2) >>> extract/cache tags 3) close the file? >>> >>> Issue N2. >>> >>> Recent changes introduced an new error during load time: "Symbol's function >>> definition is void: ede-java-root-project". After init the project can be >>> evaluated as always. As much as I can see I am not the only one suffering >>> from this bug. >>> >>> Issue N3. >>> >>> This one's easy. I believe that not all jar files supply javap with source >>> file info, thus, javap parser has to check whether it should skip the first >>> string ("Compiled from...") in program's output. Can somebody fix it? >>> >>> PS Still waiting for my papers. FSF clerk did not even answer my last >>> letter. >>> >>> >>> >>> -- >>> Yours sincerely, >>> >>> Vladimir Kazanov, >>> software developer, >>> mob. +7 (963) 304-05-12 >>> ICQ: 82042707 >>> skype: stvovka >>> email: vka...@in... >>> -- >>> >>> С уважением, >>> >>> Владимир Казанов, >>> программист, >>> моб. +7 (963) 304-05-12 >>> ICQ 82042707 >>> skype: stvovka >>> эл.почта vka...@in... >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> Cedet-devel mailing list >>> Ced...@li... >>> https://lists.sourceforge.net/lists/listinfo/cedet-devel >>> >> >> >> > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel -- With best wishes, Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-12-11 19:48:21
|
Eric M. Ludlam writes: > Hopefully David can confirm, but I think that upon integration with > Emacs all #autoload cookies on classes had to be removed. It's not that bad. In a nutshell: - We can't have autoload cookies on *methods*. This used to be possible, but that feature was completely removed during the merge. - You can put autoload cookies on classes, but *not* in the top-level files like lisp/cedet/semantic.el, lisp/cedet/ede.el, etc. Rule of thumb is: You may put an autoload on a defclass if the file contains a 'Local variables' section at the bottom which sets "generated-autoload-file". I guess I should explain the latter a bit more. The CEDET autoloads are special in that there's a two-tiered approach in Emacs proper. If you look into a compiled Emacs source, you'll see the following loaddefs.el files: ./lisp/loaddefs.el ./lisp/cedet/ede/loaddefs.el ./lisp/cedet/srecode/loaddefs.el ./lisp/cedet/semantic/loaddefs.el The first file contains the autoloads which are immediately availabe after Emacs startup. This file must *not* contain any autoloads for EIEIO classes. The reason for this is that otherwise EIEIO would be loaded directly at Emacs startup, and that is not wanted. The other three loaddefs.el are loaded when you actually require EDE, SRecode or Semantic, resp. They may contain class autoloads (and they do). > I'm not sure what I did that broke the current scheme, as things > 'worked for me' when I was done. > > The EDE autoloader (in ede/auto.el) is supposed to recognize the class, > and load them if needed, but that doesn't work if someone sticks the > class directly into their .emacs file. > > In theory, you would need a: > > (require 'ede/cpp-root) > > in front of all project declarations. > > Maybe these two project types are an ok thing to autoload. They should be autoloaded through `ede-add-project-autoload', and that used to work. Alex now has put autoloads in front of the classes, but that should not be necessary. Something else must have broke. -David |
From: Eric M. L. <er...@si...> - 2012-12-11 23:57:25
|
On 12/11/2012 02:48 PM, David Engster wrote: > Eric M. Ludlam writes: >> Hopefully David can confirm, but I think that upon integration with >> Emacs all #autoload cookies on classes had to be removed. > > It's not that bad. In a nutshell: > > - We can't have autoload cookies on *methods*. This used to be possible, > but that feature was completely removed during the merge. > > - You can put autoload cookies on classes, but *not* in the top-level > files like lisp/cedet/semantic.el, lisp/cedet/ede.el, etc. Rule of > thumb is: You may put an autoload on a defclass if the file contains a > 'Local variables' section at the bottom which sets > "generated-autoload-file". > > I guess I should explain the latter a bit more. The CEDET autoloads are > special in that there's a two-tiered approach in Emacs proper. If you > look into a compiled Emacs source, you'll see the following loaddefs.el > files: > > ./lisp/loaddefs.el > ./lisp/cedet/ede/loaddefs.el > ./lisp/cedet/srecode/loaddefs.el > ./lisp/cedet/semantic/loaddefs.el > > The first file contains the autoloads which are immediately availabe > after Emacs startup. This file must *not* contain any autoloads for > EIEIO classes. The reason for this is that otherwise EIEIO would be > loaded directly at Emacs startup, and that is not wanted. The other > three loaddefs.el are loaded when you actually require EDE, SRecode or > Semantic, resp. They may contain class autoloads (and they do). Thanks for explaining. I'll capture this in the style guide. >> I'm not sure what I did that broke the current scheme, as things >> 'worked for me' when I was done. >> >> The EDE autoloader (in ede/auto.el) is supposed to recognize the class, >> and load them if needed, but that doesn't work if someone sticks the >> class directly into their .emacs file. >> >> In theory, you would need a: >> >> (require 'ede/cpp-root) >> >> in front of all project declarations. >> >> Maybe these two project types are an ok thing to autoload. > > They should be autoloaded through `ede-add-project-autoload', and that > used to work. Alex now has put autoloads in front of the classes, but > that should not be necessary. Something else must have broke. The ede autoloader can't work for classes that are created in a .emacs file directoy. It only works for projects that are detected automatically based on file location. Eric |
From: David E. <de...@ra...> - 2012-12-10 19:05:56
|
Vladimir Kazanov writes: > While waiting for CEDET to parse my imports (Java, but in this particular case > it does not matter) I've noticed that emacs launches a flymake subprocess for > each and every of them, which gives my laptop a hard time. I made a simple > check: > > $ rgrep find-file-noselect * | wc -l > 128 > > Not all of those are wrong, of course, but some definitely are. There's got to > be a better way to do background parsing, as find-file-hook is a popular way to > add extra functionality. Is there a better way to 1) open a file 2) extract/ > cache tags 3) close the file? For parsing buffers, they need to be properly set up. This implies several things, for example that the major mode is loaded and things like mode-local variables and overrides are correctly installed. This is why we can't just use 'insert-file-contents' or similar. However, we have a special wrapper `semantic-find-file-noselect' which disables many time-consuming things when loading files, like version control, EDE and also Flymake (by setting `flymake-start-syntax-check-on-find-file' to nil). Either this setting is not sufficient anymore, or for some reason those buffers are loaded through plain `find-file-noselect'. The easiest way to find out would be to do a debug-on-entry on flymake-mode or similar (I'm not sure what is called; I've never used it) and post the resulting backtrace here. -David |
From: Eric M. L. <er...@si...> - 2012-12-11 13:18:17
|
Hi Alex, I had started a small guide, but never checked it in. I'll have to work on that some more. The ELisp manual has rules on good doc strings. I'm unsure about the autoload rules. Eric On 12/11/2012 01:19 AM, Alex Ott wrote: > Thank you Eric > > Do we have documented this anywhere? It would be nice, to have special > page for developers for such things... > > On Tue, Dec 11, 2012 at 3:24 AM, Eric M. Ludlam<er...@si...> wrote: >> Hi Alex, >> >> Hopefully David can confirm, but I think that upon integration with >> Emacs all #autoload cookies on classes had to be removed. I'm not sure >> what I did that broke the current scheme, as things 'worked for me' when >> I was done. >> >> The EDE autoloader (in ede/auto.el) is supposed to recognize the class, >> and load them if needed, but that doesn't work if someone sticks the >> class directly into their .emacs file. >> >> In theory, you would need a: >> >> (require 'ede/cpp-root) >> >> in front of all project declarations. >> >> Maybe these two project types are an ok thing to autoload. >> >> Eric >> >> On 12/10/2012 10:57 AM, Alex Ott wrote: >>> Hi >>> >>> I believe, that issue N2 should be fixed with commit that i did right >>> now - I added autoloads for class definitions. >>> >>> I can look to issue N3 - maybe you know which jar files produced such behaviour? >>> >>> On Mon, Dec 10, 2012 at 3:22 PM, Vladimir Kazanov<vka...@in...> wrote: >>>> Hi, everyone! >>>> >>>> Three issues today :-) >>>> >>>> Issue N1. >>>> >>>> While waiting for CEDET to parse my imports (Java, but in this particular >>>> case it does not matter) I've noticed that emacs launches a flymake >>>> subprocess for each and every of them, which gives my laptop a hard time. I >>>> made a simple check: >>>> >>>> $ rgrep find-file-noselect * | wc -l >>>> 128 >>>> >>>> Not all of those are wrong, of course, but some definitely are. There's got >>>> to be a better way to do background parsing, as find-file-hook is a popular >>>> way to add extra functionality. Is there a better way to 1) open a file 2) >>>> extract/cache tags 3) close the file? >>>> >>>> Issue N2. >>>> >>>> Recent changes introduced an new error during load time: "Symbol's function >>>> definition is void: ede-java-root-project". After init the project can be >>>> evaluated as always. As much as I can see I am not the only one suffering >>>> from this bug. >>>> >>>> Issue N3. >>>> >>>> This one's easy. I believe that not all jar files supply javap with source >>>> file info, thus, javap parser has to check whether it should skip the first >>>> string ("Compiled from...") in program's output. Can somebody fix it? >>>> >>>> PS Still waiting for my papers. FSF clerk did not even answer my last >>>> letter. >>>> >>>> >>>> >>>> -- >>>> Yours sincerely, >>>> >>>> Vladimir Kazanov, >>>> software developer, >>>> mob. +7 (963) 304-05-12 >>>> ICQ: 82042707 >>>> skype: stvovka >>>> email: vka...@in... >>>> -- >>>> >>>> С уважением, >>>> >>>> Владимир Казанов, >>>> программист, >>>> моб. +7 (963) 304-05-12 >>>> ICQ 82042707 >>>> skype: stvovka >>>> эл.почта vka...@in... >>>> >>>> ------------------------------------------------------------------------------ >>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>>> Remotely access PCs and mobile devices and provide instant support >>>> Improve your efficiency, and focus on delivering more value-add services >>>> Discover what IT Professionals Know. Rescue delivers >>>> http://p.sf.net/sfu/logmein_12329d2d >>>> _______________________________________________ >>>> Cedet-devel mailing list >>>> Ced...@li... >>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel >>>> >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> Cedet-devel mailing list >> Ced...@li... >> https://lists.sourceforge.net/lists/listinfo/cedet-devel > > > |
From: Vladimir K. <vka...@in...> - 2012-12-11 17:15:05
|
Eric, my mistake. Problems with Flymake do not come from javap. I checked things on my small testing sandbox - no problem. It is another feature causing the problem: semantic-symref-symbol. In my middle-sized project (300-400k lines of Java code) it takes ages to complete. Right now I am watching a custom log file full of "Flymake launching for <project-file-name-here>" mesages, and "top" shows tens of Flymake subprocesses. I do not know how that part of code works, but it looks like it tries parse everything in the project. On Tue, Dec 11, 2012 at 8:18 PM, Eric M. Ludlam <er...@si...>wrote: > Hi Alex, > > I had started a small guide, but never checked it in. I'll have to > work on that some more. > > The ELisp manual has rules on good doc strings. I'm unsure about the > autoload rules. > > Eric > > On 12/11/2012 01:19 AM, Alex Ott wrote: > > Thank you Eric > > > > Do we have documented this anywhere? It would be nice, to have special > > page for developers for such things... > > > > On Tue, Dec 11, 2012 at 3:24 AM, Eric M. Ludlam<er...@si...> > wrote: > >> Hi Alex, > >> > >> Hopefully David can confirm, but I think that upon integration with > >> Emacs all #autoload cookies on classes had to be removed. I'm not sure > >> what I did that broke the current scheme, as things 'worked for me' when > >> I was done. > >> > >> The EDE autoloader (in ede/auto.el) is supposed to recognize the class, > >> and load them if needed, but that doesn't work if someone sticks the > >> class directly into their .emacs file. > >> > >> In theory, you would need a: > >> > >> (require 'ede/cpp-root) > >> > >> in front of all project declarations. > >> > >> Maybe these two project types are an ok thing to autoload. > >> > >> Eric > >> > >> On 12/10/2012 10:57 AM, Alex Ott wrote: > >>> Hi > >>> > >>> I believe, that issue N2 should be fixed with commit that i did right > >>> now - I added autoloads for class definitions. > >>> > >>> I can look to issue N3 - maybe you know which jar files produced such > behaviour? > >>> > >>> On Mon, Dec 10, 2012 at 3:22 PM, Vladimir Kazanov<vka...@in...> > wrote: > >>>> Hi, everyone! > >>>> > >>>> Three issues today :-) > >>>> > >>>> Issue N1. > >>>> > >>>> While waiting for CEDET to parse my imports (Java, but in this > particular > >>>> case it does not matter) I've noticed that emacs launches a flymake > >>>> subprocess for each and every of them, which gives my laptop a hard > time. I > >>>> made a simple check: > >>>> > >>>> $ rgrep find-file-noselect * | wc -l > >>>> 128 > >>>> > >>>> Not all of those are wrong, of course, but some definitely are. > There's got > >>>> to be a better way to do background parsing, as find-file-hook is a > popular > >>>> way to add extra functionality. Is there a better way to 1) open a > file 2) > >>>> extract/cache tags 3) close the file? > >>>> > >>>> Issue N2. > >>>> > >>>> Recent changes introduced an new error during load time: "Symbol's > function > >>>> definition is void: ede-java-root-project". After init the project > can be > >>>> evaluated as always. As much as I can see I am not the only one > suffering > >>>> from this bug. > >>>> > >>>> Issue N3. > >>>> > >>>> This one's easy. I believe that not all jar files supply javap with > source > >>>> file info, thus, javap parser has to check whether it should skip the > first > >>>> string ("Compiled from...") in program's output. Can somebody fix it? > >>>> > >>>> PS Still waiting for my papers. FSF clerk did not even answer my last > >>>> letter. > >>>> > >>>> > >>>> > >>>> -- > >>>> Yours sincerely, > >>>> > >>>> Vladimir Kazanov, > >>>> software developer, > >>>> mob. +7 (963) 304-05-12 > >>>> ICQ: 82042707 > >>>> skype: stvovka > >>>> email: vka...@in... > >>>> -- > >>>> > >>>> С уважением, > >>>> > >>>> Владимир Казанов, > >>>> программист, > >>>> моб. +7 (963) 304-05-12 > >>>> ICQ 82042707 > >>>> skype: stvovka > >>>> эл.почта vka...@in... > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > >>>> Remotely access PCs and mobile devices and provide instant support > >>>> Improve your efficiency, and focus on delivering more value-add > services > >>>> Discover what IT Professionals Know. Rescue delivers > >>>> http://p.sf.net/sfu/logmein_12329d2d > >>>> _______________________________________________ > >>>> Cedet-devel mailing list > >>>> Ced...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel > >>>> > >>> > >>> > >>> > >> > >> > ------------------------------------------------------------------------------ > >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > >> Remotely access PCs and mobile devices and provide instant support > >> Improve your efficiency, and focus on delivering more value-add services > >> Discover what IT Professionals Know. Rescue delivers > >> http://p.sf.net/sfu/logmein_12329d2d > >> _______________________________________________ > >> Cedet-devel mailing list > >> Ced...@li... > >> https://lists.sourceforge.net/lists/listinfo/cedet-devel > > > > > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > -- Yours sincerely, Vladimir Kazanov, software developer, mob. +7 (963) 304-05-12 ICQ: 82042707 skype: stvovka email: vka...@in... -- С уважением, Владимир Казанов, программист, моб. +7 (963) 304-05-12 ICQ 82042707 skype: stvovka эл.почта vka...@in... |