Neil Conway wrote:
> On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
> > I never liked "cell" myself. It is too vague to me. But I see your
> > point that list_head you would think returns the head of the list, not
> > the first element in the list.
>
> I'm not sure what you mean: list_head() re
On 27-Apr-04, at 10:07 PM, Tom Lane wrote:
[ ... on the topic of list_union(), list_union_int() and friends ]
I guess the real question in my mind is whether there is any true gain
in symmetry or readability by doing it this way.
I think there's a small gain: everything else being equal, an API wi
On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
I never liked "cell" myself. It is too vague to me. But I see your
point that list_head you would think returns the head of the list, not
the first element in the list.
I'm not sure what you mean: list_head() returns the "head of the list",
which i
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Most of your suggestions are agreeable; a few minor quibbles follow.
>
> >> lfirstcell new function to get first cell, or NULL if none
> > [...]
> >> llastnode llastcell
>
> > What do you think of list_head() and list_tail() instead?
Neil Conway <[EMAIL PROTECTED]> writes:
> Most of your suggestions are agreeable; a few minor quibbles follow.
>> lfirstcell new function to get first cell, or NULL if none
> [...]
>> llastnodellastcell
> What do you think of list_head() and list_tail() instead?
No strong objection, though
(To resurrect an old thread, I've finally got some time to devote to
this; I'll post a patch once I've got something ready for public
consumption.)
On 23-Mar-04, at 4:59 PM, Tom Lane wrote:
Let's see ... fleshing out this idea a bit, here's a rundown of all the
symbols in pg_list.h and suggested
>
> On Mar 25, 2004, at 1:21, Neil Conway wrote:
>
>> I think the lack of good Win32 support (unless rectified before the
>> release of 7.5) is a pretty major problem with Arch -- that alone
>> might be sufficient to prevent us from adopting it.
>
> I don't do Windows, but my understanding i
On 25-Mar-04, at 3:03 PM, Dustin Sallings wrote:
I don't do Windows, but my understanding is that tla is as well
supported on Windows as postgres is.
David Wheeler disagrees:
A serious weakness of arch is that it doesn't work well on
Windows-based systems, and it's not clear if that will ever c
On Mar 25, 2004, at 9:22, Magnus Naeslund(t) wrote:
> You can use distributed revision control systems as centralized
> systems, but not vice-versa.
>
Not true, the other way around exists, that is what svk does.
From its description, svk sounds like a completely different system:
``svk is
On Mar 25, 2004, at 1:21, Neil Conway wrote:
I think the lack of good Win32 support (unless rectified before the
release of 7.5) is a pretty major problem with Arch -- that alone
might be sufficient to prevent us from adopting it.
I don't do Windows, but my understanding is that tla is as well
On Mar 25, 2004, at 5:05, Jan Wieck wrote:
The difference here is that instead of submitting a patch for review,
which is then frozen, the branch owner can (and that means some will,
no matter what your intentions are) keep modifying the branch during
the review process, other than just keeping
Dustin Sallings wrote:
>
> You can use distributed revision control systems as centralized
> systems, but not vice-versa.
>
Not true, the other way around exists, that is what svk does.
> As far as understanding the simplicity of arch (if you wanted to
> understand the problems it solves
On Thu, Mar 25, 2004 at 08:05:05AM -0500, Jan Wieck wrote:
> The difference here is that instead of submitting a patch for review,
> which is then frozen, the branch owner can (and that means some will, no
> matter what your intentions are) keep modifying the branch during the
> review process,
Neil Conway said:
> I don't think anything mentioned in this thread so far would be an
> enormous improvement over what we have now. However, I am still open to
> trying Arch or SVN: in the long run, I think the productivity gain
> from even an incremental improvement in the development toolset
Dustin Sallings wrote:
On Mar 24, 2004, at 20:29, Tom Lane wrote:
Not here. You want me to trust some bit of code (with absolutely zero
understanding of the source text it's hacking on) to figure out how to
resolve conflicting patches? That sounds like a recipe for big-time
unhappiness.
The id
On 25-Mar-04, at 12:25 AM, Dustin Sallings wrote:
It's definitely not a magic tool that makes bad code good and
conflicting patches happy. It solves other problems, though.
I don't think anything mentioned in this thread so far would be an
enormous improvement over what we have now. However, I
On Mar 24, 2004, at 20:29, Tom Lane wrote:
Not here. You want me to trust some bit of code (with absolutely zero
understanding of the source text it's hacking on) to figure out how to
resolve conflicting patches? That sounds like a recipe for big-time
unhappiness.
The idea is that it's the resp
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> I would guess that better merging might be a real motivation for
> people. If a patch that takes a month to develop can still apply
> cleanly despite significant code drift in the interrem, I could see
> that as a real motivating factor.
Not her
On Wednesday 24 March 2004 06:03 pm, Dustin Sallings wrote:
> There's not a lot of GUI in arch, but star-merge is fairly incredible.
> This is how tla (the main arch implementation) itself is developed.
> Lots of branches in lots of archives by lots of people.
I would guess that better mer
On Mar 24, 2004, at 18:22, Magnus Naeslund(t) wrote:
The new buzz is distributed versioning systems these days, but i
question if that is called for in the vast majority of projects out
there.
You can use distributed revision control systems as centralized
systems, but not vice-versa.
But ofc
Christopher Kings-Lynne wrote:
What's needed is a good window client like WinCVS, however...
Chris
There is a number of those, our shop uses (and makes programs for) both
windows and unix (and might soon use mac's aswell), so it's very
important that there exists a good client for each. Especia
It does have some downsides that I have found, most notibly that the
size of your sources you have in your working copy are essentially
doubled. There is a copy in your .svn directory that allows the
offline status, diff, and revert commands to work.
What's needed is a good window client
On Mar 24, 2004, at 13:22, David Garamond wrote:
From what I read here and there, BitKeeper excels primarily in merging
(good merging is apparently a very complex and hard problem) and GUI
stuffs.
There's not a lot of GUI in arch, but star-merge is fairly incredible.
This is how tla (the main
Dustin Sallings wrote:
On Mar 24, 2004, at 11:45, David Garamond wrote:
So one might ask, what *will* motivate a die-hard CVS user? A
real-close Bitkeeper clone? :-)
Since it's illegal for anyone who uses Bitkeeper's free license to
contribute to another project, does anyone know if there ar
On Mar 24, 2004, at 11:45, David Garamond wrote:
So one might ask, what *will* motivate a die-hard CVS user? A
real-close Bitkeeper clone? :-)
Since it's illegal for anyone who uses Bitkeeper's free license to
contribute to another project, does anyone know if there are any
features in Bitkeep
Frank Wiles wrote:
Why? not that I'm for a chance from something that isn't broken, but
what advantages does subversion give us over what we already have?
Subversion has lots of "little" benefits, but nothing that would be
a major incentive to switch. The biggest benefits I can think of
of
On Mar 24, 2004, at 7:29, Frank Wiles wrote:
[cool feature list]
Arch has all of that except for the checking out part of a directory
thing (would you really just check out the backend, submit a change,
and not build and test it?).
Additionally:
* Repositories can be easily replicated so c
On Tue, 23 Mar 2004 23:03:03 -0400 (AST)
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
>
> > Which brings me to another question .. has anybody considered using
> > subversion instead of CVS ?
>
> Why? not that I'm for a chance from something
On Mar 23, 2004, at 11:45, Tom Lane wrote:
AFAICS, though, CVS is not broken for our needs. I don't see an
adequate reason to change.
Yes, of course. I guess my point is that if you're going to move away
from CVS, please don't just jump to ``slightly better CVS.''
I'm looking forward to a wo
On Tue, Mar 23, 2004 at 01:16:51PM -0500, Bruce Momjian wrote:
> I agree a renaming of list functions is good. If we had kept the
> original Berkeley code as-is, we would have a lot fewer developers
> today. :-) Making drastic cleanups is often worthwile. I write
> backend code and still can't
Neil Conway <[EMAIL PROTECTED]> writes:
> [ replace lcons with lprepend ]
BTW ... you may or may not consider this relevant, but "prepend" is not
a word, it's only a hackish neologism. I can't find it at all in Random
House, and the Oxford English Dictionary lists it only as a "v. rare"
synonym f
Neil Conway <[EMAIL PROTECTED]> writes:
> It just doesn't strike me that "construction" is a very useful way to
> talk about what this operation is actually doing, and is asymmetric
> with lappend() for no good reason. The operation is "prepending" an
> element to an existing list, so why not gi
On 23-Mar-04, at 10:31 PM, Tom Lane wrote:
How do you mean it's no longer the case? ListCell looks exactly like a
cons cell to me.
Sorry, thinko on my part. I meant to say that lcons() is a Lispy name,
which suggests a Lispy implementation. This is no longer the case.
While lcons() isn't that ba
Neil Conway <[EMAIL PROTECTED]> writes:
> On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
>> No, lcons is one of the names that I think we should stick with on
>> historical grounds. It's widely used in the backend and it has the
>> right connotations for anyone who's ever used Lisp.
> I think it has e
On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?
Why? not that I'm for a chance from something that isn't broken, but what
advantages does subversion give us over what we already have?
Marc
Neil Conway wrote:
> On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
> > No, lcons is one of the names that I think we should stick with on
> > historical grounds. It's widely used in the backend and it has the
> > right connotations for anyone who's ever used Lisp.
>
> I think it has exactly the *wron
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> lconsno change
>> lconsi lcons_int
>> lconso lcons_oid
> Should these be lnew or something clearer than cons-truct?
No, lcons is one of the names that I think we should stick with on
histori
Tom Lane wrote:
> lcons no change
> lconsilcons_int
> lconsolcons_oid
>
Should these be lnew or something clearer than cons-truct?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+
I wrote:
> Let's see ... fleshing out this idea a bit, here's a rundown of all the
> symbols in pg_list.h and suggested new names:
Sheesh ... I forgot that I intended to do s/list_/l/g on that.
Doing so brings up one problem, which is that the old version of
lremove() conflicts with the new namin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What does the 'n' stand for in ncons? I also felt that lcons
> (construct) and nconc(concat) were too similarly named.
I think nconc is a direct copy from the Lisp original; whatever its
origins are, they're back in Lisp prehistory. I don't mind renami
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Neil Conway wrote:
> >> Tom objected to changing the names:
>
> > I agree a renaming of list functions is good. If we had kept the
> > original Berkeley code as-is, we would have a lot fewer developers
> > today. :-) Making drastic
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> Tom objected to changing the names:
> I agree a renaming of list functions is good. If we had kept the
> original Berkeley code as-is, we would have a lot fewer developers
> today. :-) Making drastic cleanups is often worthwile.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I assume you are doing away with the FastList hack too, aren't you?
Yup, we'll get to revert that junk too.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading th
On Tue, Mar 23, 2004 at 05:00:14AM -0500, Neil Conway wrote:
[...]
> The basic idea is to ditch the Lisp-style linked list representation
> (in which a "list" is merely a pointer to the head node), and adopt a
> new List struct like so:
I assume you are doing away with the FastList hack too, a
On Mar 23, 2004, at 8:39, Sailesh Krishnamurthy wrote:
Which brings me to another question .. has anybody considered using
subversion instead of CVS ?
My guess would be only people who haven't used arch. :)
Seriously, though. Decentralized, disconnected revision control is a
lot nicer to wor
On Tue, 23 Mar 2004 08:39:21 -0800
Sailesh Krishnamurthy <[EMAIL PROTECTED]> wrote:
> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?
I for one would love to see more Open Source projects like PostgreSQL
move to using subversion instead of CV
Neil Conway <[EMAIL PROTECTED]> writes:
> The known remaining issues that need to be addressed are:
> (1) API naming
I'll keep my mouth shut about this one until some other people have had
a chance to weigh in...
> (3) Apply the work to CVS, and update the rest of the tree for the new
> API
> T
Re changing APIs or not.
I agree with Tom that an incremental change is easier. More
importantly, it is also easier to test your implementation.
Even if everybody agrees that the API should be changed, IMO a better
way would be to first use your implementation with the old API and go
through som
48 matches
Mail list logo
