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 is
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
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() returns the
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 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?
No strong
(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
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
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
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 is
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,
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 and
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
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 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 a
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
quote who=Dustin Sallings
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
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
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
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 that isn't
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
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
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
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
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.
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
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
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 here. You
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
I'd like to wrap up the linked list rewrite, and get the code into CVS
reasonably soon. If you're unfamiliar with the motivations for
redesigning the linked list code, check the archives for previous
discussions, such as:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02204.html
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
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
The
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
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,
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
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.
I
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 cleanups is
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 renaming
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 naming
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
+
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
historical
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 *wrong*
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 [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 exactly
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
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 give it a
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 for
46 matches
Mail list logo
