Another OOP issue

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Another OOP issue

David Bateman-2
Ok, attached is the latest version of my toy galois field class (though
its already useful as is, but a duplicate of whats in octave-forge).
There are two versions of the isprimitive function, one that can be
called with matrix arguments and another with galois fields.

The version that takes a galois field manipulates the data and then
hands it off to the generic version. So @gf/isprimitive calls isprimitive.

If I run

addpath("/home/adb014/octave/galois")
isprimitive(gf([1,1,1]))

then everything is fine. However, on the second call the galois field
version of isprimitive is not called. and I get

isprimitive(gf([1,0,1]))
error: rem: complex arguments are not allowed
error: called from:
error:
/home/adb014/octave/code/octave-3.1-build/../octave-3.1-hg/scripts/general/rem.m

at line 61, column 5
error:   /home/adb014/octave/galois/isprimitive.m at line 3, column 1

which is just rem complaining about getting a galois field.

So it seems that the fact that @gf/isprimitive calls isprimitive is
somehow removing the overloading of isprimitive. Any ideas?

Regards
David

PS: Sending through gmail to *@octave.org consistently has DNS failures.
Can we dump the arsehole who poisoned the octave DNS record.


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

galois.tar.bz2 (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

octave.org DNS problems (was: Another OOP issue)

John W. Eaton-6
On 24-Sep-2008, David Bateman wrote:

| PS: Sending through gmail to *@octave.org consistently has DNS failures.
| Can we dump the arsehole who poisoned the octave DNS record.

Yeah, does anyone know if this is likely to go away after some period
of time, or are we screwed until we find out which nameservers have
the bad info?  I now see that

  host -vt ns octave.org

usually returns the correct result of

  Trying "octave.org"
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60617
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

  ;; QUESTION SECTION:
  ;octave.org.                    IN      NS

  ;; ANSWER SECTION:
  octave.org.             81204   IN      NS      dns2.cae.wisc.edu.
  octave.org.             81204   IN      NS      dns1.cae.wisc.edu.

  ;; ADDITIONAL SECTION:
  dns2.cae.wisc.edu.      13651   IN      A       128.104.201.24
  dns1.cae.wisc.edu.      9204    IN      A       144.92.12.24

  Received 110 bytes from 65.24.7.10#53 in 27 ms

but occasionally returns

  Trying "octave.org"
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31496
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;octave.org.                    IN      NS

  ;; ANSWER SECTION:
  octave.org.             14400   IN      NS      7412619160.ourkeepset.com.
  octave.org.             14400   IN      NS      7412619162.ourkeepset.com.

  Received 92 bytes from 65.24.7.10#53 in 108 ms

instead.  the nsX.sbusiness.net nameservers are no longer appearing in
the output and earlier in the week they were consistently returning
bad results.  The only two nameservers that should be listed for the
octave.org domain are dns{1,2}.cae.wisc.edu, and they have the correct
information as far as I can tell.

jwe
Reply | Threaded
Open this post in threaded view
|

Another OOP issue

John W. Eaton-6
In reply to this post by David Bateman-2
On 24-Sep-2008, David Bateman wrote:

| Ok, attached is the latest version of my toy galois field class (though
| its already useful as is, but a duplicate of whats in octave-forge).
| There are two versions of the isprimitive function, one that can be
| called with matrix arguments and another with galois fields.
|
| The version that takes a galois field manipulates the data and then
| hands it off to the generic version. So @gf/isprimitive calls isprimitive.
|
| If I run
|
| addpath("/home/adb014/octave/galois")
| isprimitive(gf([1,1,1]))
|
| then everything is fine. However, on the second call the galois field
| version of isprimitive is not called. and I get
|
| isprimitive(gf([1,0,1]))
| error: rem: complex arguments are not allowed
| error: called from:
| error:
| /home/adb014/octave/code/octave-3.1-build/../octave-3.1-hg/scripts/general/rem.m
|
| at line 61, column 5
| error:   /home/adb014/octave/galois/isprimitive.m at line 3, column 1
|
| which is just rem complaining about getting a galois field.
|
| So it seems that the fact that @gf/isprimitive calls isprimitive is
| somehow removing the overloading of isprimitive. Any ideas?

Please try the following patch.  Gah, who wrote this mess anyway?

Thanks,

jwe


# HG changeset patch
# User John W. Eaton <[hidden email]>
# Date 1222456781 14400
# Node ID 344c9b6532a2dbc0f5ca9a8abff57530f4225274
# Parent  265a821f65557a6925bb84df943473159e7e82e4
symtab.cc (out_of_date_check_internal): fix order of arguments in call to load_path::find_method

diff --git a/src/ChangeLog b/src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2008-09-26  John W. Eaton  <[hidden email]>
+
+ * symtab.cc (out_of_date_check_internal):
+ Fix order of arguments in call to load_path::find_method.
+
 2008-09-26  David Bateman  <[hidden email]>
 
  * ov-class.h (idx_vector index_vector (void) const): Declare new
diff --git a/src/symtab.cc b/src/symtab.cc
--- a/src/symtab.cc
+++ b/src/symtab.cc
@@ -194,7 +194,7 @@
       // decide whether it came from a relative lookup.
 
       if (! dispatch_type.empty ())
- file = load_path::find_method (nm, dispatch_type,
+ file = load_path::find_method (dispatch_type, nm,
        dir_name);
 
       if (file.empty ())
Reply | Threaded
Open this post in threaded view
|

Re: octave.org DNS problems (was: Another OOP issue)

David Bateman
In reply to this post by John W. Eaton-6

John W. Eaton wrote
| PS: Sending through gmail to *@octave.org consistently has DNS failures.
| Can we dump the arsehole who poisoned the octave DNS record.

Yeah, does anyone know if this is likely to go away after some period
of time, or are we screwed until we find out which nameservers have
the bad info?
The problem is that the poisoning could happen any on the upstream DNS servers from where the request happens. finding which one needs patching is a major pain. However, the problem with octave.org seems to be pretty widespread so the first once to check that it is correctly patch is the one serving octave.org. The caches of the downstream servers will eventually be flushed and fix the issues.

I'm just surprised that I haven't heard of a lot of other sites suffering these type of problems recently.

D.
 
Reply | Threaded
Open this post in threaded view
|

Re: octave.org DNS problems (was: Another OOP issue)

John W. Eaton-6
On 26-Sep-2008, dbateman wrote:

| John W. Eaton wrote:
| >
| > | PS: Sending through gmail to *@octave.org consistently has DNS failures.
| > | Can we dump the arsehole who poisoned the octave DNS record.
| >
| > Yeah, does anyone know if this is likely to go away after some period
| > of time, or are we screwed until we find out which nameservers have
| > the bad info?
| >
|
| The problem is that the poisoning could happen any on the upstream DNS
| servers from where the request happens. finding which one needs patching is
| a major pain. However, the problem with octave.org seems to be pretty
| widespread so the first once to check that it is correctly patch is the one
| serving octave.org. The caches of the downstream servers will eventually be
| flushed and fix the issues.
|
| I'm just surprised that I haven't heard of a lot of other sites suffering
| these type of problems recently.

I sent most of the following to you earlier, but I think it should be
posted on the list as well.

I still think the problem is that the ns0{3,4}.sbusiness.net
nameservers are listed is the problem.  I don't think these are coming
from a bad cache.  As far as I know, they really are listed as
nameservers for the domain when they should not be there now.  Back
whent eh domain was first registered in 2000, we initially had
ns0{1,2,3,4}.sbusiness.net listed as the nameservers for octave.org
because those were the default nameservers available with whoever was
the registrar for the domain (Network Solutions?).  Later, we replaced
ns0{1,2}.sbusiness.net with two wisc.edu nameservers, but apparently
the ns0{3,4}.sbusiness.net servers were never removed.  At some point
the sbusiness.net nameservers disappeared, and now it looks like some
squatter has picked them up and has them returning bogus information.
At least I think that's what is happening.  If we could find out for
sure whether the ns0{2,3}sbusiness.net nameservers really are listed
as secondary nameservers for the domain, that would help.  If they
are listed, they should be removed.  Otherwise, I think we will
continue to have problems.  If they are not listed as secondary
nameservers for the domain in the registrar records, then I think we
have a cache problem.

The reason it is taking a while to determine whether the sbusiness.net
nameservers are still actually listed in the domain registrar records
is that I don't own the domain.  The registration was contributed, and
the person who set it up is the technical and administrative contact
for the domain and he is busy and has been slow to respond.  We are
also trying to fix that problem by transferring the registration, but
unfortunately this may take some time.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: octave.org DNS problems

Bill Denney-5
John W. Eaton wrote:

> I still think the problem is that the ns0{3,4}.sbusiness.net
> nameservers are listed is the problem.  I don't think these are coming
> from a bad cache.  As far as I know, they really are listed as
> nameservers for the domain when they should not be there now.  Back
> whent eh domain was first registered in 2000, we initially had
> ns0{1,2,3,4}.sbusiness.net listed as the nameservers for octave.org
> because those were the default nameservers available with whoever was
> the registrar for the domain (Network Solutions?).  Later, we replaced
> ns0{1,2}.sbusiness.net with two wisc.edu nameservers, but apparently
> the ns0{3,4}.sbusiness.net servers were never removed.  At some point
> the sbusiness.net nameservers disappeared, and now it looks like some
> squatter has picked them up and has them returning bogus information.
> At least I think that's what is happening.  If we could find out for
> sure whether the ns0{2,3}sbusiness.net nameservers really are listed
> as secondary nameservers for the domain, that would help.  If they
> are listed, they should be removed.  Otherwise, I think we will
> continue to have problems.  If they are not listed as secondary
> nameservers for the domain in the registrar records, then I think we
> have a cache problem.
Sbusiness are (almost) definitely listed in the registrar records.
Checking with whois returns them and wisc.edu with them listed first.
Using dig to find out about the DNS records indicates that they just
respond by default to any requests pointing to their web servers.

The info just needs to be changed at the registrars.

Have a good day,

Bill