P4COM / LWW binding, release 0.2
Unable to parse email body. Email id is 7997
Unable to parse email body. Email id is 7997
Hi, ndl Is it possible to generate loadable lisp patchs from LW Editor's Changed Definitions facility, just like the old Lisp Machine time? Recently I read some Symbolics documents, there's a "Patch Facility" in Symbolics' defsystem, seems quite advance. I'm interesting in how LispWorks' patch (public & private) bundle be made for a long time. I don't think these patch files are hand-wrote. Regards, Chun Tian (binghe) > > This binding allows access from LWW to the Perforce SCM > (http://www.perforce.com/). It's been almost 5 years since I released > 0.1 so I reckoned it was time for an upgrade. > > New at 0.2: > > * Improved presentation for "p4 opened" > * Add "p4 revert" > * Process P4CONFIG file (so you can work with multiple repositories) > * Improved albeit incomplete support for filenames containing spaces > * Incorporates latest version of p4com.dll > > I've been using this daily for years. If I have any other users out > there I'll be pleased to hear from them as it might improve the > chances of there ever being a 0.3 > > http://www.nicklevine.org/p4com/ > > - nick >
On Wed, 23 Apr 2008 07:29:04 +0100, Nick Levine <ndl@ravenbrook.com> writes: > Is it possible to generate loadable lisp patchs from LW Editor's > Changed Definitions facility, just like the old Lisp Machine time? > > Recently I read some Symbolics documents, there's a "Patch > Facility" in Symbolics' defsystem, seems quite advance. > > There's a strong argument that this facility did not necessarily serve > its owners well, so if you come across one use it with care. In > particular, make sure you can always continue to build your system > from scratch (i.e. that a force compilation into a clean image will > succeed). You could always build the deployed version of the system from scratch, since you could ask for a particular version of the source code of a given system. (The patch facility included version control.) Whether or not the *latest* version of the source code would compile is another matter, outside the scope of a source control facility. > Also, what you change in the source is not always what or how you > patch in the field. Human intervention - at least to review the change > and consider how it will behave - is always required. The patch facility included a workflow for review and signoff of changes; that's what the "Reviewed By" and "Approved" things in the version/stream part of the system were about. In my view, which is largely based on experience with CVS, it's too bad modern systems don't have some of the features and integration with the IDE that we had 20 years ago.
On Wed, 23 Apr 2008 10:25:40 +0100, Tim Bradshaw <tfb@cley.com> writes: > it was remarkably easy to end up with systems which could not be > rebuilt from cold, and that's not good at all. Patches are > fundamentally a bad idea, and making them easier is not a good thing. How is this different from people checking in changes to CVS that wind up breaking the system? That's what happens almost all the time in the environments I've worked in.
Unable to parse email body. Email id is 8005
On Wed, 23 Apr 2008 12:52:25 +0100, davef@lispworks.com <davef@lispworks.com> writes: > Indeed. In addition to what you listed, there are the users of changed > macros and inline functions to consider. You must also arrange for the > appropriate optimize qualities to be in effect at patch compile time, > along with any (EVAL-WHEN (:COMPILE-TOPLEVEL ...)) forms. So there are > important considerations outside of the source code you actually edited. Yes, the system needs to track all the callers, and be aware of the optimize settings (just like it's aware of the file-global attributes like the readtable). It certainly doesn't work to just look at some text; it has to have extensive side information somewhere.
On Wed, 23 Apr 2008 13:19:20 +0100, Nick Levine <ndl@ravenbrook.com> writes: > I believe (maybe someone who was there can clarify) that this is > precisely what happened at Symbolics. When I was there we rebuilt the system regularly, but there was some magical bootstrapping that only a few people knew. The patch system was a set of software managment tools for controlling and auditing source changes, tools for partially automating creation of comprehensive and less buggy changes, for documented change histories and live version control, and for deploying patches to the field. Where I come from, we call that "a Good thing"! Could always be better, though!
Unable to parse email body. Email id is 8172
On Tue, 3 Jun 2008 16:52:31 +0100 (BST), "Nick Levine" <ndl@ravenbrook.com> said: > > Date: Tue, 22 Apr 2008 19:48:51 +0100 (BST) From: Nick Levine > <ndl@ravenbrook.com> > > This binding allows access from LWW to the Perforce SCM ( > http://www.perforce.com/). It's been almost 5 years since I > released 0.1 so I reckoned it was time for an upgrade. > > [...] > > I've been using this daily for years. If I have any other users out > there I'll be pleased to hear from them as it might improve the > chances of there ever being a 0.3 > > Seeing as the total number of responses I received wasn't even plusp: > huzzah! I can consider myself under no obligation to do any more work > on this. > > Question: is anyone reading this (other than me) a Perforce user? Me too. Incidentally I have just uncovered a memory leak in the p4com.dll which causes it to leak a copies of the strings it sends back. This is unlikely to hurt typical interactive use, but I have a server using it that was slowly starving itself of memory. I'll be sending a patch off to Robert Cowham (p4com.dll author) once it is tested... - Dom