Subject: RE: [hackers-il] Long Live the Minute Difference

From: Omer Musaev <[email-masked]>
Date: Tue, 18 Dec 2001 09:47:24 +0200

> -----Original Message-----
> From: Shlomi Fish [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 2:29 PM
> To: Hackers-IL
> Subject: [hackers-il] Long Live the Minute Difference

[description of how Technion's lecturer missed Scheme details]

> In any case, in a discussion I had with a friend of mine I 
> suggested that
> one can protect the functions from a possibility that their utility
> functions will be over-riden like this:
> 
> (define make-rat (let ((cons cons)) (lambda (n d) (cons n d))))

Nice one:)

> 
> This is useless in this case but may be useful if the 
> expression is a bit
> more complex.
> 
> Regards,
> 
> 	Shlomi Fish

-- 
Omer Mussaev
Software Developer
Mercury Interactive / Topaz Prism R&D
Application Team 

There is no IGLU Cabal! The cabal is saving current continuation... 
saving current continuation... saving current continuation...

---

From: Omer Musaev <[email-masked]>
Date: Thu, 20 Dec 2001 12:12:05 +0200

> From: Oleg Goldshmidt [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 5:39 PM
> To: [email-masked]
> Subject: Re: [hackers-il] Long Live the Minute Difference
> 
> 
> Omer Musaev <[email-masked]> writes:
> 
> > For example - checkout the whole project, check in the 
> whole project,
> > rollback the whole project, or roll-forward it after you had rolled 
> > it back. 
> 
> This is CVS for me. I know as well as I do that there is a nice XEmacs
> interface to CVS - pcl-cvs
> 
> > In addition, various projects have ( usually ) various build 
> > options - so one-click-build procedure is supposed to change 
> > according to what project you are working right now.
> 
> For me, each project has its own Makefile. Moreover, I noticed long
> ago that 90+% of operations I do on each project are common to all or
> most of the projects. So I have a separate "project" under CVS control
> that contains boilerplate Makefile that are included in individual
> projects' Makefiles.
> 
> Different build options are handled via different make targets. Most
> are also common to various projects. I managed - with a small effort,
> really - to make my boilerplate targets flexible enough that
> individual projects (or a particular build) can modify the details
> without changing the boilerplate Makefiles.
> 
> Of course, make runs quite nicely from inside XEmacs.

You are right - XEmacs has fine support for one-click-builds, 
provided you use make or something equivalent, and it has 
nice CVS integration.

The problem is that CVS is just one of possible source-control
mechanisms, and there are others. At work I must use 2 other source 
control tools, neither of which is CVS based. Both of them do their
work pretty well, unfortunately, they are not compatible with each 
other. 

However, they do have similar interface. This leads me to conclusion
that having umbrella tool that would turn to appropriate implementation
will be more appropriate to "XEmacs - the development environment" than
CVS and make integration. 

> > In addition, there are plenty of operations on file level - source 
> > control operations, annotations ( if those are stored in external 
> > files, or in DB, or whatever - implementation of logic should not 
> > be concerned with that ).
> 
> Source control is really on a project level for me, via CVS. Actually,
> I have a bunch of make targets that roll development and production 
> releases back and forth nicely. I am not sure what you mean by
> annotations - CVS has its log and annotation facilities, so 
> it's there.

Well, as I mentioned earlier, I do use file-level source control - so 
this interface, even if not supported by CVS, is required for a perfect
platform.

> > * Cross referencing - etags is an example of cross referencing, 
> >   although I would be happier to have something like 
> SNiFF/Retriever.
> 
> I use etags, I have to look at SNiFF/Retriever.

SNiFF was a tool that did almost all tasks that I mentioned in that mail.
It had 2 versions - more powerful, which was sold for  a lot of money, and
less
powerful one ( named "SNiFF/Penguin" ), free for any use ( including 
commercial ). Retriever was a sub-tool in a SNiFF that made cross 
referencing easy.

The bad thing is that when Take Five Software, manufacturer of SNiFF, was 
acquired by Wind River, the Penguin version was discontinued. Pity. 

> 
> > * Class browsing: what is in some class? 
> > 
> > * Hierarchy browsing: what is relationship of my class in 
> whole system?
> > 
> > * Concept/models browsing: What concept is implemented by 
> my template? Is 
> >   there any concept coercion? What templates implement my concept? 
> 
> These are lacking

ECB 1.50 does kind of class browsing. Doxygen does some kind of hierarchy
browsing. Concept/models browsing is really missing. 

> > 
> > In addition to that, I would like to see code metrics of my code:  
> > 
> > * How many coupling ( in some metric ) there is in my project?
> > 
> > * How those metrics will be affected by refactoring ?
> 
> And so are these

However, those could be very useful when you talk about large and very
large projects....
  
> > In addition to that, I would like to use refactoring browser - like
> > xref.
> 
> It's there, isn't it? Oh, did you mean for C++? Does XCScope help a
> bit?

Did not try that thing...

> 
> -- 
> Oleg Goldshmidt | [email-masked] 
> "If it ain't broken, it has not got enough features yet."

There is no IGLU Cabal. The cabal is trying to compose 1 perfect tool
out of void, where 1000000 not-so-perfect tools were disposed earlier..