[QUOTE=Dubslow;383318]Ah yes, that's [URL="https://github.com/dubslow/MersenneForumAliquot/blob/master/website/py/myutils.py"]here[/URL]. Putting it in the same directory, and then also running reservations.py from that directory, ought to be fine.[/QUOTE]
myutils.py also wanted emailing.py which I found in the same place.

I am now getting the following error:
[code]E:\Mersenne\AliquotReservations>reservations_2.py spider
Traceback (most recent call last):
File "E:\Mersenne\AliquotReservations\reservations_2.py", line 80, in read_db
seq.size = int(l[-1])
ValueError: invalid literal for int() with base 10: 'wombatman'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "E:\Mersenne\AliquotReservations\reservations_2.py", line 335, in <module>
last_pid = spider(last_pid)
File "E:\Mersenne\AliquotReservations\reservations_2.py", line 219, in spider
db = read_db()
File "E:\Mersenne\AliquotReservations\reservations_2.py", line 83, in read_db
seq.index, seq.size = get_info(seq.seq)
TypeError: 'NoneType' object is not iterable[/code]
Is this due to an error in the first post of the reservations thread? I can't find anything obvious.
As far as I am aware your script should be able to handle lines without a length and iteration number. If not if I added dummy values(1 for example) would it correct them.

Sorry to keep on asking questions like this.

No worries, each question you ask is a bug in my afterthought extra-touch code. I'm in class right now though, so it'll be a few hours before I can fix it. (The first exception happened by design, but I screwed up the code to handle it...)

It might be worth you getting your mod powers back so you can test this sort of thing.

This is some pretty complex coding you must have put quite a bit of work into it. It is inevitable that there would be bugs.

LaurV, 994176 merged with 37620;
henryzz, 122884, which was causing the error, merged with 22308 and should be removed from the reservations post.

I'll push a commit to git that prints a message instead of failing. Edit: pushed.

I'm still pretty confident the actual spidering code is sound, like I said I tested it quite well while I was writing it. These errors were all reproducible on my end.

574230 had also merged apparently. I will check if the terminations thread needs updating for these.
It even reordered some sequences I have put in the wrong place.

Random fix:
The error is does'nt exist!
not doesn't exist!

It looks like fivemack's reservations today will overflow the first post.

I think we might have to be a little more complex with the detection code.
R and A for reserving and U and D for dropping would cause problems the way many people post. Taking seems to be popular as does Releasing. Releasing causes a conflict with Reserving using our current method.

We could just ask for a particular form but that seems a little strict.

574230 was very small I assume it must have been a typo when fivemack reserved it.
122884 merged next iteration so basically should have been called 22308.

[QUOTE=henryzz;383333]
Random fix:
The error is does'nt exist!
not doesn't exist!
[/QUOTE]

I stared at that for a good two minutes wondering why it looked funny, then said "eh, whatever" and committed it.

Ten minutes later I then said "oh s**t".

337344 is missing from the list.
It is broken in FactorDB (but so is another dozen).
Its current state is
[CODE]867 . 171841874709467777407137210519724745777155213118050606411137596612474196944001558441112921996396264019339265486232710 = 2 * 3 * 5 * 229848365353111144804413901788807233 * p[/CODE]

Hi,

I'm using the DataTable at [url]http://dubslow.tk/aliquot/AllSeq.html[/url] to select sequences to throw at aliqueit. Recently I stumbled upon a sequence that is broken in factorDB. I researched this a little bit and now have a suggestion and a bug report to make.

I just found this thread after opening an issue on github. So sorry for the "cross posting".

My suggestion would be to mark those broken sequences in the table because the links leading to factorFB only lead to the broken sequence. If someone wants to further enhance the sequence, the elf file from factorDB is useless and one has to find other means to enhance. One way is to use the next index as a starting point and download this elf file. Which leads me to my bug report.

In allseq.py there is a field with the broken sequences and the next good index. There is also some code that uses those good indexes as a start to determine the real end of the broken sequence. In some cases this is working in some cases it is not. Despite the fact that two sequences are twice in the list, I couldn't find a reason why some are correctly "enhanced" and some are not.

Example 1: seq 319860 is broken at i1071, the table shows it is at i1114 using the next good index i1072
Example 2: seq 706104 is broken at i937, the table shows it at i937 but using the next good index i938 I would get to i1059

correctly "enhanced": 319860 270870 337344 322686 327852
broken in table: 706104 228504 305460 296886

[QUOTE=ChristianB;403389]Hi,

I'm using the DataTable at [url]http://dubslow.tk/aliquot/AllSeq.html[/url] to select sequences to throw at aliqueit. Recently I stumbled upon a sequence that is broken in factorDB. I researched this a little bit and now have a suggestion and a bug report to make.

I just found this thread after opening an issue on github. So sorry for the "cross posting".

My suggestion would be to mark those broken sequences in the table because the links leading to factorFB only lead to the broken sequence. If someone wants to further enhance the sequence, the elf file from factorDB is useless and one has to find other means to enhance. One way is to use the next index as a starting point and download this elf file. Which leads me to my bug report.

In allseq.py there is a field with the broken sequences and the next good index. There is also some code that uses those good indexes as a start to determine the real end of the broken sequence. In some cases this is working in some cases it is not. Despite the fact that two sequences are twice in the list, I couldn't find a reason why some are correctly "enhanced" and some are not.

Example 1: seq 319860 is broken at i1071, the table shows it is at i1114 using the next good index i1072
Example 2: seq 706104 is broken at i937, the table shows it at i937 but using the next good index i938 I would get to i1059

correctly "enhanced": 319860 270870 337344 322686 327852
broken in table: 706104 228504 305460 296886[/QUOTE]

I've made a mini table of the broken sequences at the top of the table. Since the links in the main table are rendered by the Javascript, not the Python that manipulates the data, it would be substantially more work for me to modify the links for the broken ones. And this is a nice way to see all the broken sequences in one place anyway.

The rendering is rather derpy for now, but my girlfriend does web design and will be redoing the whole thing for me, so I'm not going to fuss about it quite yet.

Removing the duplicate entries seems to have solved the problem of some broken ones appearing incorrectly in the table. I have no idea why that might have been, but at any rate the issue is gone now. We should check in 3 or 4 days to be sure it doesn't recur.