From: Paul Tarvydas
Subject: self-managed freelist for class instances
Date:
Message-ID: <fkulrj$6s3$1@aioe.org>
I have a class of things that will flash into and out of existence
frequently.
I'm thinking of managing my own free list for these objects.
Is there some combination of :before (:after?) methods that will allow me to
allocate storage from the free list instead of having make-instance
allocate the storage automagically?
For example: new instance creation -> if free list empty, then allocate new
storage, else pop free item from free list and poke values into the slots.
I can see how to do this with defuns, but I don't know how to get
make-instance to behave this way.
Or is the idea stupid for some reason?
thanx
pt
On Dec 26, 11:51 pm, Paul Tarvydas <········@visualframeworksinc.com>
wrote:
> I have a class of things that will flash into and out of existence
> frequently.
>
> I'm thinking of managing my own free list for these objects.
>
> Is there some combination of :before (:after?) methods that will allow me to
> allocate storage from the free list instead of having make-instance
> allocate the storage automagically?
>
> For example: new instance creation -> if free list empty, then allocate new
> storage, else pop free item from free list and poke values into the slots.
>
> I can see how to do this with defuns, but I don't know how to get
> make-instance to behave this way.
>
> Or is the idea stupid for some reason?
>
> thanx
> pt
Using 'RESOURCES' is one option.
http://common-lisp.net/project/bknr/static/lmman/resour.xml
From: Richard M Kreuter
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <87hci5ugte.fsf@progn.net>
Paul Tarvydas <········@visualframeworksinc.com> writes:
> Is there some combination of :before (:after?) methods that will
> allow me to allocate storage from the free list instead of having
> make-instance allocate the storage automagically?
Most people interpret CLHS 11.1.2.1.2 point 19 [1] to entail that you
can't [2] specialize MAKE-INSTANCE on instances of STANDARD-CLASS. So
the most conforming thing to do is probably to wrap MAKE-INSTANCE in a
constructor that finds you an unused instance and refreshes it.
--
RmK
[1] http://www.lispworks.com/reference/HyperSpec/Body/11_abab.htm
[2] Strictly, "the consequences are undefined", so an implementation
might define the consequences, or might let you get away with doing
it without promising that they'll always do so, etc.
From: Peder O. Klingenberg
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <ks4pe4zb1m.fsf@beto.netfonds.no>
Richard M Kreuter <·······@progn.net> writes:
> Paul Tarvydas <········@visualframeworksinc.com> writes:
>
>> Is there some combination of :before (:after?) methods that will
>> allow me to allocate storage from the free list instead of having
>> make-instance allocate the storage automagically?
>
> Most people interpret CLHS 11.1.2.1.2 point 19 [1] to entail that you
> can't [2] specialize MAKE-INSTANCE on instances of STANDARD-CLASS. So
> the most conforming thing to do is probably to wrap MAKE-INSTANCE in a
> constructor that finds you an unused instance and refreshes it.
Not being a language lawyer, I can't say if it's portable or not, but
I once got away with defining a new metaclass deriving from
STANDARD-CLASS, and then specializing MAKE-INSTANCE on that metaclass,
eventually doing CALL-NEXT-METHOD. "User" classes needing the special
behaviour simply specified my metaclass in their class options, and
instantiation with MAKE-INSTANCE just worked.
This was years ago, using cmucl version *mumble*, and the CVS
repository containing the implementation has seems to have been lost
in time and server upgrades. But who knows, this might work for the
OP as well, depending on his circumstances.
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
From: Richard M Kreuter
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <87abnwus39.fsf@progn.net>
·····@news.klingenberg.no (Peder O. Klingenberg) writes:
> Richard M Kreuter <·······@progn.net> writes:
>
>> Most people interpret CLHS 11.1.2.1.2 point 19 [1] to entail that
>> you can't [2] specialize MAKE-INSTANCE on instances of
>> STANDARD-CLASS.
>
> Not being a language lawyer, I can't say if it's portable or not, but
> I once got away with defining a new metaclass deriving from
> STANDARD-CLASS, and then specializing MAKE-INSTANCE on that metaclass,
> eventually doing CALL-NEXT-METHOD. "User" classes needing the special
> behaviour simply specified my metaclass in their class options, and
> instantiation with MAKE-INSTANCE just worked.
I think that might not be conforming without introducing two
metaclasses:
(defclass custom-class (standard-class)
())
;; CUSTOM-CLASS is a direct instance of STANDARD-CLASS, so I think
;; this has undefined consequences.
(defmethod make-instance ... ((class custom-class))
...)
(defclass sub-custom-class (custom-class)
())
;; SUB-CUSTOM-CLASS is not a direct instance of any standardized
;; class, so I think this oughtta work.
(defmethod make-instance ... ((class sub-custom-class))
...)
OTOH, if all you want is to specialize MAKE-INSTANCE on classes,
rather than metaclasses, then you only need the one class of
metobjects:
(defclass my-object ()
()
(:metaclass custom-class))
(defmethod make-instance ... (((object my-object)) ...)
...)
Again, this is territory where implementations might allow what the
standard does not require.
P� Wed, 26 Dec 2007 23:51:51 +0100, skrev Paul Tarvydas
<········@visualframeworksinc.com>:
> I have a class of things that will flash into and out of existence
> frequently.
>
> I'm thinking of managing my own free list for these objects.
>
> Is there some combination of :before (:after?) methods that will allow
> me to
> allocate storage from the free list instead of having make-instance
> allocate the storage automagically?
>
> For example: new instance creation -> if free list empty, then allocate
> new
> storage, else pop free item from free list and poke values into the
> slots.
>
> I can see how to do this with defuns, but I don't know how to get
> make-instance to behave this way.
>
> Or is the idea stupid for some reason?
>
> thanx
> pt
>
Not quite sure what you want to do that for. Creation itself is not a
particularly expensive operation.
If it is speed you are after you are better off allocating it on the stack
and using structure rather than classes. Method dispatch can be expensive.
structure access may be inlined and can be as cheap as a aref.
declaring the types of the attributes may also help (it depends on what
you are storing)
If you want to reuse the area you could use a lexical closure
example:
(defstruct (rectangle (:conc-name rec-))
(tlx 0 :type fixnum)
(tly 0 :type fixnum)
(brx 0 :type fixnum)
(bry 0 :type fixnum))
(let ((border (make-rectangle :tlx 0 :tly 0 :brx 400 :bry 400)))
(defun draw-border ()
(declare (optimize (speed 3) (safety 0)))
(let ((bd border))
(move-to (rec-tlx bd) (rec-tly bd))
(draw-to (rec-brx bd) (rec-tly bd))
(draw-to (rec-brx bd) (rec-bry bd))
(draw-to (rec-tlx bd) (rec-bry bd))
(draw-to (rec-tlx bd) (rec-tly bd)))))
CL-USER 2 > (disassemble 'draw-border)
200A9C1A:
0: BFB79E0A20 move edi, 200A9EB7 ; #(#S(RECTANGLE
:TLX 0 :TLY 0 :BRX 400 :BRY 400))
5: E9CEFAFFFF jmp 200A96F2
200A96F2:
0: 55 push ebp
1: 89E5 move ebp, esp
3: 33F6 xor esi, esi
5: 56 push esi
6: 56 push esi
7: 897DF8 move [ebp-8], edi
10: 8B7DF8 move edi, [ebp-8]
13: 8B7705 move esi, [edi+5]
16: 8975FC move [ebp-4], esi
19: 8B7DFC move edi, [ebp-4]
22: 8B7F09 move edi, [edi+9]
25: 57 push edi
26: 8B45FC move eax, [ebp-4]
29: 8B400D move eax, [eax+D]
32: B502 moveb ch, 2
34: FF155008B221 call [21B20850] ; MOVE-TO
40: 8B7DFC move edi, [ebp-4]
43: 8B7F11 move edi, [edi+11]
46: 57 push edi
47: 8B45FC move eax, [ebp-4]
50: 8B400D move eax, [eax+D]
53: B502 moveb ch, 2
55: FF152808B221 call [21B20828] ; DRAW-TO
61: 8B7DFC move edi, [ebp-4]
64: 8B7F11 move edi, [edi+11]
67: 57 push edi
68: 8B45FC move eax, [ebp-4]
71: 8B4015 move eax, [eax+15]
74: B502 moveb ch, 2
76: FF152808B221 call [21B20828] ; DRAW-TO
82: 8B7DFC move edi, [ebp-4]
85: 8B7F09 move edi, [edi+9]
88: 57 push edi
89: 8B45FC move eax, [ebp-4]
92: 8B4015 move eax, [eax+15]
95: B502 moveb ch, 2
97: FF152808B221 call [21B20828] ; DRAW-TO
103: 8B7DFC move edi, [ebp-4]
106: 8B7F09 move edi, [edi+9]
109: 8B45FC move eax, [ebp-4]
112: 8B400D move eax, [eax+D]
115: 83EC04 sub esp, 4
118: 8B7500 move esi, [ebp]
121: 8975FC move [ebp-4], esi
124: 83ED04 sub ebp, 4
127: 8B7508 move esi, [ebp+8]
130: 897504 move [ebp+4], esi
133: 897D08 move [ebp+8], edi
136: B502 moveb ch, 2
138: C9 leave
139: FF252808B221 jmp [21B20828] ; DRAW-TO
145: 90 nop
NIL
No heap allocations and structure access functions are inlined..
--------------
John Thingstad
Paul Tarvydas wrote:
> I have a class of things that will flash into and out of existence
> frequently.
>
> I'm thinking of managing my own free list for these objects.
>
> Is there some combination of :before (:after?) methods that will allow me to
> allocate storage from the free list instead of having make-instance
> allocate the storage automagically?
Have you looked at specializing allocate-instance for a custom metaclass?
I am guessing your lisp offers a finalize option for instances being GCed?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Paul Tarvydas wrote:
> Or is the idea stupid for some reason?
I forgot to add, it might be hard to outperform normal behavior, and to
ask if you have actually profiled the code and observed this to be a
problem, or if you are just assuming it will be. The latter is generally
a bad idea, progammers tend to guess wrong on these things.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Daniel Weinreb
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <Dppdj.3411$4m5.1803@trnddc02>
Ken Tilton wrote:
>
>
> Paul Tarvydas wrote:
>> Or is the idea stupid for some reason?
>
> I forgot to add, it might be hard to outperform normal behavior, and to
> ask if you have actually profiled the code and observed this to be a
> problem, or if you are just assuming it will be. The latter is generally
> a bad idea, progammers tend to guess wrong on these things.
>
> kt
>
I agree. Creating objects that don't last long is often
extremely cheap, particularly in Lisp implementations with
generational GC's.
Paul Tarvydas wrote:
> I have a class of things that will flash into and out of existence
> frequently.
>
> I'm thinking of managing my own free list for these objects.
>
> Is there some combination of :before (:after?) methods that will allow me to
> allocate storage from the free list instead of having make-instance
> allocate the storage automagically?
>
> For example: new instance creation -> if free list empty, then allocate new
> storage, else pop free item from free list and poke values into the slots.
>
> I can see how to do this with defuns, but I don't know how to get
> make-instance to behave this way.
>
> Or is the idea stupid for some reason?
Are you sure that this is a bottleneck in your application?
Modern garbage collectors should be good at this already, and
implementing your own object pools can actually have an adversary effect
on such garbage collectors. (Based on the fact that you hold references
to such objects, they will assume that these objects are long-lived,
when they actually aren't.)
Bottom line: Profile your application first and find out where the real
overheads are.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Paul Tarvydas
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <fl0i77$at6$1@aioe.org>
Pascal Costanza wrote:
> Paul Tarvydas wrote:
[snip]
> Are you sure that this is a bottleneck in your application?
>
> Modern garbage collectors should be good at this already, and
> implementing your own object pools can actually have an adversary effect
> on such garbage collectors. (Based on the fact that you hold references
> to such objects, they will assume that these objects are long-lived,
> when they actually aren't.)
>
> Bottom line: Profile your application first and find out where the real
> overheads are.
Dang, that's advice I only give to other people :-).
Yes, after reading the responses and sleeping on it, I will probably go
ahead with the straight-forward implementation and see (+ measure) what
happens.
I'm in the middle of implementing "indication" boxes (Jef Raskin's "The
Humane Interface" - faint highlights that appear when you mouse over an
object), which are all discarded and recalculated on every single
mouse-move event. XOR'ing the boxes onto the window is probably much more
expensive than creating and destroying the instances.
Maybe what I really need is a set of hints on how to develop an instinct for
modern g.c. so that I can override my ancient prejudices?
pt
Paul Tarvydas wrote:
> Pascal Costanza wrote:
>
>
>>Paul Tarvydas wrote:
>
> [snip]
>
>>Are you sure that this is a bottleneck in your application?
>>
>>Modern garbage collectors should be good at this already, and
>>implementing your own object pools can actually have an adversary effect
>>on such garbage collectors. (Based on the fact that you hold references
>>to such objects, they will assume that these objects are long-lived,
>>when they actually aren't.)
>>
>>Bottom line: Profile your application first and find out where the real
>>overheads are.
>
>
> Dang, that's advice I only give to other people :-).
>
> Yes, after reading the responses and sleeping on it, I will probably go
> ahead with the straight-forward implementation and see (+ measure) what
> happens.
>
> I'm in the middle of implementing "indication" boxes (Jef Raskin's "The
> Humane Interface" - faint highlights that appear when you mouse over an
> object), which are all discarded and recalculated on every single
> mouse-move event.
Ouch. The only thing that should happen on each mouse-move event is the
decision as to which object (if any) is under the mouse. You can then
have a single long-lived indicator box instance with an "indicatee" slot
for the object under the mouse, and a visible? slot that goes to nil
when the indicatee slot goes to null. The positioning happens at the
window level, and requires a simple geometric transfrom up from the
indicatee geometry to the window geometry if you are using a nested
coordinate scheme. But using a single box is extra credit, as is even
optimizing only when the indicatee actually changes, because...
> XOR'ing the boxes onto the window is probably much more
> expensive than creating and destroying the instances.
... none of that latency gets within orders of magnitude of what a user
would notice.
>
> Maybe what I really need is a set of hints on how to develop an instinct for
> modern g.c. so that I can override my ancient prejudices?
Install Cello and trace a few key low-level functions, then move the
mouse around. Or use my count-it utility a few places, the trace will
make the interface unusable so much is going on. You will be surprised
at how much work a modern CPU can do these days, and your ancientness
might be more about having a feel for that than a feel for GC.
ps. A final thing to remember is that these would be short-lived
instances and those are handled pretty well by modern GCs. or so I here.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Paul Tarvydas wrote:
> Maybe what I really need is a set of hints on how to develop an instinct for
> modern g.c. so that I can override my ancient prejudices?
Google for "object pools", "generational garbage collectors" and
"ephemeral garbage collectors."
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Paul Tarvydas
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <fl20d3$hiu$1@aioe.org>
Pascal Costanza wrote:
> Paul Tarvydas wrote:
>
>> Maybe what I really need is a set of hints on how to develop an instinct
>> for modern g.c. so that I can override my ancient prejudices?
>
> Google for "object pools", "generational garbage collectors" and
> "ephemeral garbage collectors."
I know the theory.
It's the instinct (intuition) that I'm missing.
E.G. at what point do I need to start worrying? My instincts said
(yesterday) that I should be very worried about destroying and
instantiating new objects on every mouse-move event.
I can develop the instinct by profiling a few real apps (elapsed time =
years, probably), or by implementing and debugging my own generational GC,
but, maybe there is something less time consuming that I could do to get a
feel for what's going on?
(My main argument (to myself) today was that Smalltalk (probably) does this
sort of stuff without special optimizations, so maybe CL/CLOS is in the
same ballpark?).
pt
From: Thomas Lindgren
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <m2ejd79d87.fsf@dev.null>
Paul Tarvydas <········@visualframeworksinc.com> writes:
> Pascal Costanza wrote:
>
>> Paul Tarvydas wrote:
>>
>>> Maybe what I really need is a set of hints on how to develop an instinct
>>> for modern g.c. so that I can override my ancient prejudices?
>>
>> Google for "object pools", "generational garbage collectors" and
>> "ephemeral garbage collectors."
>
> I know the theory.
>
> It's the instinct (intuition) that I'm missing.
>
> E.G. at what point do I need to start worrying? My instincts said
> (yesterday) that I should be very worried about destroying and
> instantiating new objects on every mouse-move event.
The example that put Moore's law vs realtime events in perspective to
me was Tenenhouse et al doing software radio and media processing in
the mid-90s. (Or just consider what can be done in a single frame of
a modern OpenGL application.)
In this case, given a mouse-move every millisecond (which seems about
10-30x too often, or more), you have N*CPU/1000 cycles to handle
it. (Well, let's say you want to handle it with a 1ms deadline.) On a
modern mid-end CPU that's still 2-3 M cycles per core.
Regarding GC, I was convinced by the paper by Tarditi et al (again
mid-90s) which showed that with a generational GC and some hardware
support, e.g., a write buffer, it's fast enough for SML to just
allocate new objects/terms/conses. (Someone else did the same for
Scheme.)
I'm not sure to what extent this holds for all of Common Lisp though
-- people seem to abhor consing to a great extent and there is much
more emphasis on destructive updates. As I recall from one article,
ITA went to a great deal of trouble to avoid memory management.
(Basically using the same manual allocation/deallocation approach.)
Best,
Thomas
Thomas Lindgren <···········@*****.***> writes:
> I'm not sure to what extent this holds for all of Common Lisp though
> -- people seem to abhor consing to a great extent and there is much
> more emphasis on destructive updates. As I recall from one article,
> ITA went to a great deal of trouble to avoid memory management.
> (Basically using the same manual allocation/deallocation approach.)
That's obsolete information, from a time when some Lisp implementation
with a slow GC was used. See for example <http://lwn.net/Articles/248665/>:
: But, as it turns out, the strange things QPX did to avoid allocating
: new memory for objects that need to be on the "heap" was actually
: *slower* than allocating the objects normally and letting the GC do
: its thing.
--
Juho Snellman
From: Thomas Lindgren
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <m21w95y860.fsf@dev.null>
Juho Snellman <······@iki.fi> writes:
> Thomas Lindgren <···········@*****.***> writes:
>> I'm not sure to what extent this holds for all of Common Lisp though
>> -- people seem to abhor consing to a great extent and there is much
>> more emphasis on destructive updates. As I recall from one article,
>> ITA went to a great deal of trouble to avoid memory management.
>> (Basically using the same manual allocation/deallocation approach.)
>
> That's obsolete information, from a time when some Lisp implementation
> with a slow GC was used. See for example <http://lwn.net/Articles/248665/>:
>
> : But, as it turns out, the strange things QPX did to avoid allocating
> : new memory for objects that need to be on the "heap" was actually
> : *slower* than allocating the objects normally and letting the GC do
> : its thing.
Thanks, good to know. My rule of thumb is that it's seldom worth
worrying about consing vs reuse if your algorithm is otherwise okay,
for the previous reasons, but the counterexamples tend to stick. This
particular one seems to be sorted then.
Best,
Thomas
From: Paul Tarvydas
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <fl68iq$s25$1@aioe.org>
Argh.
Anybody know of a good, free nntp server? I just noticed that there are a
number of responses (e.g. all responses from Kenny) in this thread that do
not appear on the nntp server that I'm using (nntp.aioe.org).
pt
From: Edi Weitz
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <uy7bdxnsk.fsf@agharta.de>
On Sat, 29 Dec 2007 14:54:26 -0500, Paul Tarvydas <········@visualframeworksinc.com> wrote:
> Anybody know of a good, free nntp server?
Not free, but almost free (10 Euros per year):
http://www.individual.net/
IMHO it's definitely worth the investment. I've been using it for
years without any problems.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Paul Tarvydas <········@visualframeworksinc.com> writes:
> Argh.
>
> Anybody know of a good, free nntp server? I just noticed that there are a
> number of responses (e.g. all responses from Kenny) in this thread that do
> not appear on the nntp server that I'm using (nntp.aioe.org).
Have you not seen any responses from Kenny at all? I've used
nntp.aioe.org for a few days now and I'm sure I've seen them.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Paul Tarvydas
Subject: Re: self-managed freelist for class instances
Date:
Message-ID: <fl79t1$ofn$1@aioe.org>
Andreas Davour wrote:
> Paul Tarvydas <········@visualframeworksinc.com> writes:
>
>> Argh.
>>
>> Anybody know of a good, free nntp server? I just noticed that there are
>> a number of responses (e.g. all responses from Kenny) in this thread that
>> do not appear on the nntp server that I'm using (nntp.aioe.org).
>
> Have you not seen any responses from Kenny at all? I've used
> nntp.aioe.org for a few days now and I'm sure I've seen them.
Nope. I see Kenny stuff in other threads, but not in this one. The first
hint I got was seeing someone's reply to one of his replies. I checked
google groups and saw stuff I hadn't seen earlier.
I checked my local kill-lists and didn't see anything there. To
double-check, I downloaded and installed a completely different newsreader
(slrn, which I think uses completely different .rc files) and pointed it at
nntp.aioe.org. Same result - no Kenny responses in this particular thread
via nntp.aioe.org.
At this moment (before I hit 'send' on this message), google groups lists 20
items in this thread and my newsreader lists 17. Kenny posted 3 items, and
all are missing in my local newsreader.
This sure sounds like an inadvertent kill-list problem of my own doing. Can
you confirm that you see Kenny posts on nntp.aioe.org, all on Dec. 27?
That might help me narrow this problem down.
OTOH, my newsreader shows posts by Kenny in other threads as far back as Dec
13.
(Kenny's not in trouble, is he? On a no-fly list? Wanted by the NSA? On a
no-export list? He's not the one posting the MI5 sporge, is he? Victim of
anti-lisp extremists? On google group's payroll? :-) :-) :-).
pt
* Paul Tarvydas<············@aioe.org> :
Wrote on Sun, 30 Dec 2007 00:23:01 -0500:
|>> Anybody know of a good, free nntp server? I just noticed that there are
|>> a number of responses (e.g. all responses from Kenny) in this thread that
|>> do not appear on the nntp server that I'm using (nntp.aioe.org).
[...]
| Nope. I see Kenny stuff in other threads, but not in this one. The first
| hint I got was seeing someone's reply to one of his replies. I checked
| google groups and saw stuff I hadn't seen earlier.
|
| I checked my local kill-lists and didn't see anything there. To
| double-check, I downloaded and installed a completely different newsreader
| (slrn, which I think uses completely different .rc files) and pointed it at
| nntp.aioe.org. Same result - no Kenny responses in this particular thread
| via nntp.aioe.org.
I have had/am having similar problems with my news server. This ISP I
use (and pay) has verio upstream, and some articles are occassionally
missing, and I usually only find out when trying to go up the thread
from a response. So far, there has been no explanation.
In this particular thread, I can't even find your article
<·················@aioe.org> (fkulrj$6s3$1 @ aioe.org)
In the past people have suggested using motzarella.org for a free
service, but I just looked for a kenny-article missing from my
newsserver, <·····························@cv.net> and it is not
available there either.
Who does aioe talk to upstream?
--
Madhu
Madhu wrote:
> * Paul Tarvydas<············@aioe.org> :
> Wrote on Sun, 30 Dec 2007 00:23:01 -0500:
>
> |>> Anybody know of a good, free nntp server? I just noticed that there are
> |>> a number of responses (e.g. all responses from Kenny) in this thread that
> |>> do not appear on the nntp server that I'm using (nntp.aioe.org).
> [...]
> | Nope. I see Kenny stuff in other threads, but not in this one. The first
> | hint I got was seeing someone's reply to one of his replies. I checked
> | google groups and saw stuff I hadn't seen earlier.
> |
> | I checked my local kill-lists and didn't see anything there. To
> | double-check, I downloaded and installed a completely different newsreader
> | (slrn, which I think uses completely different .rc files) and pointed it at
> | nntp.aioe.org. Same result - no Kenny responses in this particular thread
> | via nntp.aioe.org.
>
> I have had/am having similar problems with my news server. This ISP I
> use (and pay) has verio upstream, and some articles are occassionally
> missing, and I usually only find out when trying to go up the thread
> from a response. So far, there has been no explanation.
>
> In this particular thread, I can't even find your article
> <·················@aioe.org> (fkulrj$6s3$1 @ aioe.org)
>
> In the past people have suggested using motzarella.org for a free
> service, but I just looked for a kenny-article missing from my
> newsserver, <·····························@cv.net> and it is not
> available there either.
>
> Who does aioe talk to upstream?
This is starting to feel like The Cuckoo's Egg. Hopefully it is personal
and we will find one of my flamees at the bottom of the thing. In the
meantime I will be working on a jingle for the "I Want My Kenny Flames"
campaign.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Andreas Davour escribi�:
> Paul Tarvydas <········@visualframeworksinc.com> writes:
>
>> Argh.
>>
>> Anybody know of a good, free nntp server? I just noticed that there are a
>> number of responses (e.g. all responses from Kenny) in this thread that do
>> not appear on the nntp server that I'm using (nntp.aioe.org).
>
> Have you not seen any responses from Kenny at all? I've used
> nntp.aioe.org for a few days now and I'm sure I've seen them.
>
> /andreas
>
I'm not getting Kenny's posts in reader.greatnowhere.com, but I do see
them in news.readfreenews.net. I'm suspecting it is an issue of spam
filtering (reader.greatnowhere.com uses cleanfeed for this), because I
never had him blacklisted. I sent a message to the administrator but
with no response so far.
It'a a relief to know this is a server problem. For a momment I feared
that Ken could have been eaten by one of his own hounds. :)
Leandro