AliWin.exe discussion
 

I have programmed a Windows GUI to run Aliqueit. The program, which I call AliWin, does not change Aliqueit in any way, but provides an easy method to control some aspects and adds a few capabilities. Some features of the program are:
[code]
-queue several numbers (up to 1000) with different digit sizes
-Aliqueit and subsequent programs are still run within a console window for top performance
-Aliqueit is stopped once the size is reached
-Aliqueit can work past the size until it finds a composite cofactor that is 80% of the size and survives ECM
-wget can retrieve and submit sequence data automatically
-automatic and manual saves to the db do not interrupt the running Aliqueit instance
-open/edit several of the files via a single button click for each
-menu and help are self-contained within source in single AliWin.cpp file
-AliWin.cpp compiles under Dev-C++ 4.9.9.2
[/code]
Current shortcomings:
[code]
-only written for Win32
-doesn't detect db merges
-all basic files have to be in the same directory as AliWin
-limited source code documentation
-amateurish implementation of routines
-lack of error-checking
[/code]
I have been running this program against several numbers in the db, most recently those under the 838k line in the Subproject #5 thread. It still has several anomolies, but I am checking to see if this program has any interest to anyone else. I can make the source and/or win32 binary available, if there is interest. I will also field questions in this thread.

Additionally, if someone has a request for additional features, bring them up here. I'll see if they would be easy (for me) to implement.

What language is it written in?
please post binaries and preferably source

[quote=henryzz;213344]What language is it written in?
please post binaries and preferably source[/quote]
I would guess C++:
[quote=EdH]-menu and help are self-contained within source in single AliWin.cpp file
-AliWin.cpp compiles under Dev-C++ 4.9.9.2[/quote]
Meanwhile, though, sounds like a really cool idea! :smile:

It is indeed C++ developed for a Windows environment. Some of the API routines say they are supported by Win2000 and newer. I haven't tried it on anything but the WinXP that I used to build it.

Please be patient. I hope to have a page built in the next day or so that will have the single binary AliWin.exe and the single source AliWin.cpp along with screen shots and instructions.

For now, it is built to be used within the directory C:\MathWork\Aliqueit. All the other files also need to be located in that same directory. I hope to make it less particular soon. You will still need to acquire all the YAFU.exe, msieve.exe, aliqueit.exe, ggnfs package, etc. and add them to the aliqueit directory in order for it to run.

I will put up details on using it when I get the page done. I kind of wanted to see the level of interest at this point.

The page will be [URL]http://www.starreloaders.com/edhall/AliWin/AliWin.html[/URL]. I will post update notices and answer comments and questions here in this thread.

A preview:

This looks awesome!

Your project will definitely aid in some of the discrepancies of understanding how to use some of the factoring tools.

Your GUI looks great!

[QUOTE=EdH;213398]You will still need to acquire all the YAFU.exe, msieve.exe, aliqueit.exe, ggnfs package, etc. and add them to the aliqueit directory in order for it to run.[/QUOTE]

Wouldn't it be slick to auto-detect the latest binaries and download if needed.

Oh, I guess I want my cake and ice cream and eat it too. :)

Just a couple cosmetic suggestions.

- The "Run aliqueit" and "Stop aliqueit" can be the same button, just toggle the text of what would be the next change. (Maybe a color background.)

- I'm assuming the Status box and the list box contains information about the state of the current index. If they post the pre-factored size along with the remaining composite size, keep it consistent. Always one before the other.

Other than that, it looks good.
Great job!!

Thanks for the interest and feedback.

Mention anything that seems like it might be a good thing to have. Although I may not implement everything, I certainly won't if I'm not aware of it. Auto version check? I don't know - maybe after I get a handle on the more pressing things...

Run and Stop are separate right now because I was having a problem with stopping it. I may take your suggestion, though.

The Status box is showing the current state of the current number. In the above example the number 216840 has a current size of 106 and is working to 120. You can notice in the aliqueit window that the current cofactor is a c100.

The list shows completed numbers with the current size first and then the size it was to work to. This should be consistent with the Status box. For the 91/88 and 90/88, both were to work to 88, but the "Run ECM above digit cutoff" setting took them to that size, or that was the size in the database when retrieved. I chose to put the sizes first in case the number being worked is too large for the display, and to help keep things lined up somewhat.

So, I think I am consistent, unless I missed your meaning.

I am currently working on the web page in the area of explaining how to set everything up and where to get all the different programs/packages. I hope to have something up soon, but I have already changed things that affect the help file messages, so I'll have to rework those prior to making the program available.

Thanks again for the feedback and for your patience.

[QUOTE=EdH;213487]The Status box is showing the current state of the current number. In the above example the number 216840 has a current size of 106 and is working to 120. You can notice in the aliqueit window that the current cofactor is a c100.

The list shows completed numbers with the current size first and then the size it was to work to. This should be consistent with the Status box. For the 91/88 and 90/88, both were to work to 88, but the "Run ECM above digit cutoff" setting took them to that size, or that was the size in the database when retrieved. I chose to put the sizes first in case the number being worked is too large for the display, and to help keep things lined up somewhat.

So, I think I am consistent, unless I missed your meaning.[/QUOTE]

I misunderstood the numbers. My assumption was incorrect.

I'll read the manual when it comes out.

Looks cool, can't wait for the download to be available. :smile:
A few notes based on what I've seen:
The radio boxes (circles) on the right side of the program should be check boxes (squares) instead. They're not exclusive in any way, which is what radio boxes imply. Rather, they're all separate options that can be used in any combination, which is what check boxes imply.
Do the "Open [file name]" boxes just tell Windows to open them in the default program, or are you telling it what to open in (e.g. Notepad)? If the latter, is it customizable? I'd prefer it to be customizable, as I have scripts set to be run instead of opened in something, which wouldn't be useful in a situation like that.

I'm curious to see how you're doing some of the stuff behind the scenes, compared to aliperl. :smile: e.g. are you having aliqueit run a line at a time and checking it in between or allowing it to run constantly and just monitoring it? And how are you doing the "Run ECM above digit cutoff" feature? Is it like the interceptor scripts I wrote, or do you just monitor its progress (via all the files or just aliqueit.log) and watch for the SIQS/GNFS to start or what?
Are you able to modify and rebuild Aliqueit? I'd like a version that doesn't print all the config to the screen, and this would be especially useful for aliperl and AliWin, if AliWin runs aliqueit one line at a time.

Thanks for the feedback.

I can change the radioboxes easily, but will probably wait for now. I didn't like how close the checkboxes started on the left edge and don't (yet) know how to get them over a bit.

The open filename boxes are hard-coded to particular programs, which is a pain and I will eventually change, when I get some other things settled. A particular pain is that the first time you open factmsieve.py or factMsieve.pl, you can't use Notepad, because it doesn't interpret the EOLs correctly. And, using Wordpad is not so easy - Wordpad doesn't come up by just calling it. You have to exclusively go get it and hope it will be in the same location in various Win OSs. Eventually I plan to add the ability to set up the launch string for each file and have it saved in the AliWin.cfg file that currently just keeps the radiobox data.

I'm turning Aliqueit fully loose. I never did like to step through one line at a time. I couldn't figure out how to get FileSystemWatcher implemented (a lack of class knowledge - a real shortcoming on my part), so I'm using a Timer to check the size from the .elf and the last line in Aliqueit.log. If the size is met and the extra ECM is unchecked, the program sends a WM_Close and a TerminateProcess to the aliqueit window. If the extra ECM box is checked, it also looks for "Running qs" or "Running gnfs" to flag a close. I tried piping the aliquet output directly into AliWin for display, but it really increased the time and wasn't stable.
I thought about just "Windoizing" Aliqueit, but I don't think it would run as efficiently, and I wasn't sure about some items.

The source is pretty rough and clumsy, but I hope to smooth it out and add more internal documentation as it progresses. There are still a few things missing or not done to my liking, simply because I don't know how. I program to learn how to program and lack a good foundation in a lot of critcal areas.


[B]Note to everyone:[/B] I have the page partly constructed, if anyone would like to visit it and comment here, I'd welcome that feedback, too. I hope to have the code up in the next day or two. (And, yes, I already know there is an extra "Starting out..." title mysteriously sitting in the YAFU instructions.):smile:

More later...

AliWin is now available for testing
 

The page is complete, with source and binary available at:

[URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]AliWin - A GUI by Edwin C. Hall for Aliqueit by Mikael Klasson[/URL]

I have added step-by-step instructions for setting up a complete set of files to run aliquot sequences and to start using AliWin.

Please critique the page, information and program as completely as you wish. Please use this thread for all comments/questions/critiques.

Even add "nice-to-have" ideas. I might not implement them or it may take a while, but I am interested in all ideas.

There is a t before yafu-64k-Win32.exe on the first help screen.

Edit: The status box and opening the current .elf only work if you have result_file_prefix set to alq_ in aliqueit.ini.

[quote=10metreh;213695]There is a t before yafu-64k-Win32.exe on the first help screen.[/quote]
Only in the screen shot, it's not like that in the program.
[quote=10metreh;213695]Edit: The status box and opening the current .elf only work if you have result_file_prefix set to alq_ in aliqueit.ini.[/quote]
Also the automatic download/upload don't work if the prefix isn't alq_. (i.e. everything about checking the .elf file doesn't work with a different prefix, because it assumes that's what it'll be)
Edit: If nothing else, add a note to the page or help that you must keep result_file_prefix as the default of alq_.

Thanks for pointing these out. I caught the "t" after I saved the image:smile:

I'd rather read the ini file to get the prefix, than make it such that you need to run defaults. These are the types of things I need to know about. In fact in checking out the alq_ item, I'm noticing that aliqueit.log can be altered, too.

I have changed the radio buttons to check boxes in my copy, but they are right directly on the left edge. I can't find a way to move them to the right slightly. Maybe I can make a large control and place them all on it...

I have posted some updates:

Radio buttons are now check boxes
both aliqueit.log and the elf file prefix are now taken from the aliqueit.ini file.

The latest version (shown in Help>About) is now .20100501b, which means I modified it twice today.:smile:

I will add the version number to the title bar soon.

Aliqueit works with whole lines when it sends data to the db. Because of this, the current line doesn't include any of the factors found during ECM. Most of these factors can be found by Quick ECM, but there is a region of factors between the Quick ECM and the qs/gnfs that are often found when performing a full ECM run. Unless these numbers are entered manually, by retrieving them from the log, they are lost (or, more appropiately, never known) to the db.

I would like to include these factors when sending data to the db from AliWin. I can programmatically dig them out of the log file, but I don't know how to provide them to the db programmatically. Is there a format for suppying factors? Possibly, through WGET?

Or, is there something I'm missing in the way data should be submitted to have these factors included?

[quote=EdH;213768]Aliqueit works with whole lines when it sends data to the db. Because of this, the current line doesn't include any of the factors found during ECM. Most of these factors can be found by Quick ECM, but there is a region of factors between the Quick ECM and the qs/gnfs that are often found when performing a full ECM run. Unless these numbers are entered manually, by retrieving them from the log, they are lost (or, more appropiately, never known) to the db.

I would like to include these factors when sending data to the db from AliWin. I can programmatically dig them out of the log file, but I don't know how to provide them to the db programmatically. Is there a format for suppying factors? Possibly, through WGET?

Or, is there something I'm missing in the way data should be submitted to have these factors included?[/quote]
You should be able to submit the factors via the Report Factors page with wget--I believe that's the way aliqueit does its factor uploads. I would suggest looking in the aliqueit source for clues on how that works.

According to the Report Factors page, the following formats are accepted:
[code]Factor tables: <composite> = <factor1> * <factor2> * ...
Sequences: <index> . <composite> = <factor1> * <factor2> * ...
Also accepted: <index>. <composite> = <factor1>.<factor2>. ...
[URL="http://www.komite.net/laurent/soft/ecm/ecm-6.0.1.html"][COLOR=#0000ff]GMP-ECM[/COLOR][/URL] output
[URL="http://www.boo.net/~jasonp/qs.html"][COLOR=#0000ff]Msieve[/COLOR][/URL] output[/code]
Probably the simplest one to use for this would just be the "factor tables" option: composite = factor * factor * factor * etc. I'm not sure how that option (or by extension, the Sequences option) handles incomplete factorizations; my guess is that composite = factor * factor * cxx would be accepted, but I don't know how it will take composite = factor * factor where the product of all the factors given is not the composite. Some experimentation may be needed beforehand to see how this works.

Incomplete factorizations are fine. Or a URL request like this should work (is the same as using the "Report Factor" box on a composite's page):
[code]http://factordb.com/search.php?query=5000000000000000000000000000558000000000000000000000000006237&reportfac=1000000000000000000000000000099
i.e.:
http://factordb.com/search.php?query=[I]fullnum[/I]&reportfac=[I]thefactor
[/I]or, to report multiple (e.g. all known, instead of just semi-large ones) factors:
http://factordb.com/search.php?query=[I]fullnum[/I]&reportfac=[I]factor[/I]*[I]factor[/I]*[I]factor[/I]
[/code]

Thanks.

This is what I was looking for. I will be working on this and some other things as I have time.

I have changed the aliqueit.log check so it looks for size change instead of reading the whole file and checking the last line every time. I plan to change the reporting to be based on a size change in the elf file, with a possibility to send every time a new line is added or just after a certain time has passed and a new line is added. What would be a good time - 2, 4, 24 hours or, maybe user configurable? I'm thinking along the lines of having the time be a delay, such that the earliest anything is reported is after the time has elapsed, but nothing is reported until a new line is added. That way, a short delay will allow for each line to trigger, but it won't send if no line has been added, until the next line completes.

Is there a need or desire for any certain info to be displayed? What about having the working index or the last complete line from the elf? Maybe I'll play with a button that cycles through several things... I can even use that to cycle through (and add) some user configuration, like files to use to open aliqueit.log, py/pl scripts, etc.

Current version is now: .20100502 (I've also added it to the title bar.)

I suppose I should start a change list soon... before my memory fails.

I have added some functionality to AliWin. The current version is now .20100506a.

I've done some testing, but I was changing so many things today, that I started having all sorts of minor annoyances cropping up. I think I stabilized all the features and when the dust settled:

AliWin now submits all the minor factors for the unfinished last line.

The applications used to open up the various files on the left side can now be changed, although the files themselves still need to be in the same directory. Basically, If you click the new button "Edit config" you will be shown what the current applications are and can elect to change them. You then step through each one by clicking on the "Save config" button after you either keep what is there or change it to your choice. When the button changes back to "Edit config" and the edit area clears, you are through the list. You can verify the choices by choosing "Edit config" again, and if all is good, choose "No." The edits will be saved in the AliWin.cfg file upon closing, as are the options, currently.

By incorporating RichD's suggestion :smile:, the new button fit in the place of the "Stop aliqueit" one. Run and Stop are now the same toggle. (I haven't graduated to colors, yet.) Let me know if this fails. I've had some issues with it not wanting to start again due to not terminating correctly, but the button taking on the alternate state anyway.

I hope I cured an issue with corrupted elf files due to the program seeing an empty elf that was made that way by aliqueit in preparation for the first complete line. It would bump the db again and then get another partial line with the complete version concatenated onto it when aliqueit finished its first iteration.

Thanks for any and all feedback. Enjoy!

It should be easier to set all of the config files to open in a single program. (I did it by copy/pasting the program path, which made it nice and fast...but still is way more monotonous than it could be) e.g. instead of "Yes" and "No", have something like "Yes, individually", (would behave like Yes currently does) "Yes, all together", (would have you enter a program path once and apply that to all the files) and "No". (with current behavior, sans the bug I report in a few sentences :wink:)
Of course, one of those standardized dialog boxes to let you browse to the program (if only to auto-fill the path and then allow you to fine-tune it manually) would be nice, (if only optionally) but if it's too much work, that's not a big deal.
Also, there's a minor bug. If you click Edit config and then No, then click Edit config again, it has you set all the programs just like you had pressed Yes (except that the button still says Edit config, not Save config - it still saves it though).
Another minor bug: AliWin doesn't seem to be deleting the files left over from the partial factor reports. Either you left it out entirely or it's not understanding how wget is naming them correctly. Either way, it'd make it easier to have wget put it in a short file name that you can easily refer to, like wget.temp.

Would it be hard (when using aliqueit to send elf data to the DB) to pass aliqueit the last line you've sent instead of having it send the whole elf? For people like me who like watching it go up bit by bit in the DB, (when I'm watching it, anyway) sending the whole elf is rather redundant.

Thanks for the report. I appreciate all the feedback.

[quote=Mini-Geek;214215]It should be easier to set all of the config files to open in a single program. (I did it by copy/pasting the program path, which made it nice and fast...but still is way more monotonous than it could be) e.g. instead of "Yes" and "No", have something like "Yes, individually", (would behave like Yes currently does) "Yes, all together", (would have you enter a program path once and apply that to all the files) and "No". (with current behavior, sans the bug I report in a few sentences :wink:)

Of course, one of those standardized dialog boxes to let you browse to the program (if only to auto-fill the path and then allow you to fine-tune it manually) would be nice, (if only optionally) but if it's too much work, that's not a big deal.[/quote]
I'm not using special purpose dialog boxes because I couldn't get them to work without building an .rc file and I was trying to keep the source all-inclusive. That's why the menu is included instead of being in a separate file. I will study that, though.

Perhaps for now, a first message box that asks if you would like to set all the same, or maybe a YES - NO - Cancel that respectively refers to single - multiple - cancel.

[quote=Mini-Geek;214215]Also, there's a minor bug. If you click Edit config and then No, then click Edit config again, it has you set all the programs just like you had pressed Yes (except that the button still says Edit config, not Save config - it still saves it though).[/quote]
I will look into the bug tomorrow - I'm sure I fail to reset an IDYES set variable.

[quote=Mini-Geek;214215]Another minor bug: AliWin doesn't seem to be deleting the files left over from the partial factor reports. Either you left it out entirely or it's not understanding how wget is naming them correctly. Either way, it'd make it easier to have wget put it in a short file name that you can easily refer to, like wget.temp.[/quote]
I haven't been deleting any files. I probably need to know which ones to get rid of. Some get overwritten and the entire ggnfs directories are saved. I have a temp file I use for wget that should be overwritten each time. Should I delete that one after it serves no more purpose? I'm not sure which files you are referring to, but I'm not at my programming machine right now either.

[quote=Mini-Geek;214215]Would it be hard (when using aliqueit to send elf data to the DB) to pass aliqueit the last line you've sent instead of having it send the whole elf? For people like me who like watching it go up bit by bit in the DB, (when I'm watching it, anyway) sending the whole elf is rather redundant.[/quote]
I meant to change the reporting to the lines not yet uploaded. I forgot about going back to it.

I also still need to decide how I want to approach the automatic reporting - each new line - every ten lines - every couple hours, etc. I did add in a variable to track whether the elf had new lines, but didn't start using it for anything yet.

I hope to have a chance tomorrow to put a little more time into it, but I might be somewhat tied up for a couple days.

Thanks again for the feedback.

There's a minor bug in the DB that I just noticed and that you should be aware of, as it is sometimes apparent when using AliWin: if you only report very small factors (the limit for the largest prime is somewhere from 19 to 379...maybe 256?), the DB will ignore the factors.
This only has minor effects obviously (the last line won't show the known partial factorization if only tiny factors exist), just wanted to let you know.

[quote=Mini-Geek;214242]There's a minor bug in the DB that I just noticed and that you should be aware of, as it is sometimes apparent when using AliWin: if you only report very small factors (the limit for the largest prime is somewhere from 19 to 379...maybe 256?), the DB will ignore the factors.
This only has minor effects obviously (the last line won't show the known partial factorization if only tiny factors exist), just wanted to let you know.[/quote]
Thanks. I had not noticed this. I often just submit the largest factor when I manually upload - the rest fill in. I will keep this in mind.

I'm thinking of querying the db to find out what line to start with for uploads instead of trying to keep tabs. Any additional cons to this, other than there being another db interaction? It would seem easier to implement for all scenarios, at least for now.

Also, I do not currently signal an upload if you stop aliqueit. I wonder if I should...

[quote=EdH;214247]I'm thinking of querying the db to find out what line to start with for uploads instead of trying to keep tabs. Any additional cons to this, other than there being another db interaction? It would seem easier to implement for all scenarios, at least for now.[/quote]
I'd think it would be easier for the program to keep track of it, (couldn't it read the .elf or .log to know the last line pretty easily?) but I haven't really studied the workings of the program. No additional cons I can think of, besides that it will be affected by any bugs that hold up the sequence, like the 57 composite bug. (though you can only code around bugs to a certain extent, and anyway that's a largely-inconsequential effect of a bigger problem)
[quote=EdH;214247]Also, I do not currently signal an upload if you stop aliqueit. I wonder if I should...[/quote]
I'd say yes. Generally, I'd think stopping aliqueit means you'll be stopping for long enough to want the DB to be updated.

I found a minor bug: When the number finishes on a line that changed the digit size, AliWin reports the old size, not the new one. e.g. [URL="http://factordb.com/search.php?se=1&aq=842172"]842172[/URL] going to 100 digits with ECM after the digit cutoff hit a c96 on line 1264 (where AliWin stopped, as expected). On line 1264 the size changed from 102 digits to 103 digits. AliWin reported its final status as "102 / 100 842172".
I suppose you could read the size from the log file in such a case.

Also, when you're not running a number, if you click Open current .elf, it opens alq_.elf. Can it be modified to gray out or to open the last-run or next-to-be-run sequence's elf in a situation like this?

I've uploaded a new version, but it doesn't really address anything brought up today (7 May) directly. I have reworked the configure routine so that it now asks Yes, No, Cancel which corresponds to same for all, individual setting and cancel.

I have set it to send only the missing lines by querying the db for now. I have no idea what the 57 bug would do, for certain. I have been trying to find out what is causing some other error, though. Occasionally, the elf gets corrupted in a manner I can't identify. Everything looks fine if I review it, but aliqueit returns an error that says something is wrong with index 0. The only way I can fix the elf, is to delete the first line, which isn't 0 anyway. In any event, I have AliWin continuing with subsequent numbers if it closes due to an error. At the moment, the Aliqueit window closes, but for up to five seconds the Stop Aliqueit stays, then it flips to Run Aliqueit, sends info to the db, flips back to Stop Aliqueit and continues with the next number. It also does about the same thing if Aliqueit detects a merge due to the composite falling below the original value.

I did do a lot of stuff with size tracking, but I don't think I took care of the final report bug.

I'll see if I can grey the current.elf button. This definitely needs something.

Flagging a db send on stopping aliqueit should be extremely simple - "famous last words...":smile:

I do not expect to have any time tomorrow to work on the program, but hope to address the new issues on Sunday.

Thanks again for all the help ironing things out.

[QUOTE=EdH;214337]Occasionally, the elf gets corrupted in a manner I can't identify. Everything looks fine if I review it, but aliqueit returns an error that says something is wrong with index 0. The only way I can fix the elf, is to delete the first line, which isn't 0 anyway.[/QUOTE]

The first line is always line 0 not line 1. Can you post a file for which aliqueit returns this error?

[quote=10metreh;214350]The first line is always line 0 not line 1. Can you post a file for which aliqueit returns this error?[/quote]

AliWin doesn't download complete elfs, just the last line, which is incomplete. Aliqueit then erases the incomplete line when it reads the file, leaving an empty elf file until the first new complete line is ready. In this particular case, the first complete line was 661. I could not "see" anything wrong with it and unfortunately deleted the first line (661) leaving the next three and everything worked fine. I will have to wait for another occurrence to study it further.

I've done some more work and the version is now .[URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]20100509[/URL].

I have addressed several of the earlier issues, except the deletion of the extra files and the occasional misrepresentation of the size.

I'm not understanding where the search.php... files are coming from. Are they the return info when aliqueit submits lines to the db? Are these the only ones that are piling up? Would a deletion of search.* be a good move, or dangerous?

The size of the current (in work) iteration looks like it will take a little bit of work to change a bunch of things around. It only seems to happen when aliqueit is stopped on the very first line with a new size. Under normal circumstances, AliWin will only stop on the second line, or later, of a new size. But, sometimes, especially using the extra ECM option, that "later" will be a new size, too.

I have witnessed the ignoring of the really small factors by the db and wondered whether I should even be concerned. But, in the interest of being as complete as possible, perhaps I should try to discover a way to add them. Is there a way to invoke the "Quick ECM" via wget?

OK, now to some things I [B]have[/B] done:

The current.elf button now displays a message below it, if there is no current.elf. I didn't want to load a previous .elf, because it is a [I]current[/I].elf button. And, the only reason it should not work properly is if there is no current number. If everything is working correctly, if there is no current number the list has been completed, so there are no further ones, either.

I've added a submit to db when aliqueit is stopped, if the Auto Send option is set.

I'll be addressing the other things again when I have some more free time.

Thanks again for all the feedback.

[quote=EdH;214494]I'm not understanding where the search.php... files are coming from. Are they the return info when aliqueit submits lines to the db?[/quote]
They're the page that loads when you submit the factors for a single number to the DB using [URL]http://factordb.com/search.php?query=fullnum&reportfac=factor*factor*factor[/URL]
[quote=EdH;214494]Are these the only ones that are piling up?[/quote]
AFAICT yes. This is because the other wget requests use -O to direct the output to a useful location.
[quote=EdH;214494]Would a deletion of search.* be a good move, or dangerous?[/quote]
That could work, and I don't foresee any problems, but it's always a bit more dangerous to use a wildcard than to delete a single file.
Here's an easy fix: Add "-O nul" to wget's command line for sending factors for one number. This tells wget to write it to the file 'nul' (equivalent to Unix's '[URL="http://en.wikipedia.org/wiki//dev/null"]/dev/null[/URL]': "/dev/null or the null device is a special file that discards all data written to it").
Or you could use -O to redirect it to a real temporary file (wget.temp?). That way it will keep overwriting one file instead of piling up useless files.
[quote=EdH;214494]I have witnessed the ignoring of the really small factors by the db and wondered whether I should even be concerned. But, in the interest of being as complete as possible, perhaps I should try to discover a way to add them. Is there a way to invoke the "Quick ECM" via wget?[/quote]
AFAICT using Quick ECM requires knowing the number's DB id. This can be found by querying the DB for that number and reading the right place in the file. (e.g. query [URL]http://factordb.com/search.php?query=12345[/URL] and look for <a href="search.php?id=26589252&detail=1">(Show)</a> and see that the id is 26589252) Once you have that, to do Quick ECM, query [URL]http://factordb.com/search.php?id=164654400&qecm164654400=Quick+ECM[/URL] where 164654400 is the id.

I already have all of the direct wget lines ending with either temp.elf (probably shouldn't be .elf) or the real alq_#####.elf. That's why I wondered if the aliqueit -(s)end command was generating them somehow, but that didn't seem to be the source either. Maybe one of my temp.elf's isn't coded right...

I'll have to explore the id a little more. I also still need to check the db for merges. I need to see if I can catch that info with one of the calls I'm already making.

Not sure I'll have much time today, but we'll see if I can sneak some in.

[quote=EdH;214534]I already have all of the direct wget lines ending with either temp.elf (probably shouldn't be .elf) or the real alq_#####.elf. That's why I wondered if the aliqueit -(s)end command was generating them somehow, but that didn't seem to be the source either. Maybe one of my temp.elf's isn't coded right...[/quote]
There are three places that call wget directly. This one puts it in temp.elf:[code] strcpy(logLine, "wget \"http://factordb.com/search.php?se=1&aq=");
strcat(logLine, aliNumber[0]);
strcat(logLine, "&action=last&text=Text&raw=1\" -O temp.elf");
[/code]And this one puts it in the real elf:[code] strcpy(elfBuf, "wget \"http://factordb.com/search.php?se=1&aq=");
strcat(elfBuf, aliNumber[0]);
strcat(elfBuf, "&action=last&text=Text&raw=1\" -O ");
strcat(elfBuf, elfName);
[/code]But this one doesn't tell it where to put it, so it puts it in "search.php[...]":[code] strcpy(logLine, "wget \"http://factordb.com/search.php?query=");
strcat(logLine, number);
strcat(logLine, "&reportfac=");
//insert the factors
strcat(logLine, "\"");
[/code]As I said, if you add "-O nul" to this last one, it will discard the data instead of writing it to "search.php[...]".
Or you could write that to some other temporary file, (temp.html or some such) and then you could look at the page and see if you need to do Quick ECM, and if you do then find the id and run Quick ECM on it.

The aliqueit -s calls don't leave behind any temp files.

My latest version (yesterday's) has the following:
[code]
strcpy(logLine, "wget \"[URL]http://factordb.com/search.php?query[/URL]=");
strcat(logLine, number);
strcat(logLine, "&reportfac=");
//insert the factors
strcat(logLine, " [B]-O temp.elf[/B]\"");
[/code]
and, I was still getting search.php... files. And they weren't earlier ones - they showed current creation times. I'll have to play some more when I get a chance.

Are you using the latest version, and if so, are you still getting the extra files?

Thanks!

[quote=EdH;214548]My latest version (yesterday's) has the following:

Are you using the latest version, and if so, are you still getting the extra files?[/quote]
I wasn't using the latest version, but it's just got slightly different problems. :smile:
I just upgraded, and I'm still getting the extra files. But now they're named:[code]search.php@query=9169902108495986364695760938521849197599458583032068761522738237723668391744671546114680&reportfac=4152298947971%2A61%2A47%2A5%2A3%2A2%2A2%2A2 [B]-O temp.elf[/B]
or, shorter and more generally:
search.php@query=[full number]&reportfac=[factors, separated by %2A] [B]-O temp.elf[/B][/code](the only change was the addition of "-O temp.elf" to the end)
This is because, if you look carefully at the command line you're building now, the code:
[code]
strcpy(logLine, "wget \"[URL]http://factordb.com/search.php?query[/URL]=");
strcat(logLine, number);
strcat(logLine, "&reportfac=");
//insert the factors
strcat(logLine, " -O temp.elf\"");
[/code]Generates a command line like:
[code]wget "http://factordb.com/search.php?query=[number]&reportfac=[factors] [B]-O temp.elf[/B]"[/code]Yep, you don't have the closing double quote in the right place. Fix that and it should work like the others.
Since this isn't an .elf file, but an .html file, I recommend naming it something like temp.html, wget_temp, or wget.temp. This will also eliminate any potential conflicts by not knowing which command last wrote to temp.elf, which makes reading from the output of either of these wget commands much more reliable.

Thanks Mini-Geek,

I had just discovered what was going on, but not yet, why. You've explained it. And, I'll go with temp.html, since it's that kind of code.

I've put the new version up. It's now .[URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]20109510[/URL]. And, I added links to the files near the top of the page, so you don't have to scroll down to find them. They are now right under the version line.

Thanks again for all the help.

The new code looks good. :tu:
[quote=EdH;214559]Thanks again for all the help.[/quote]
No problem. :smile:

I've uploaded a new version - .[URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]20100512[/URL]

Nothing really new, but I've worked with the size reporting so it should be more accurate now. It will now stop on the first iteration of the digit size (most of the time), if extra ECM is off. Due to the five second delay between checks, another line might be added, if factored quickly enough.

Reloading numbers may show the current size-1 instead of the correct current size because the resident elf won't include the unfinished line. But, the reported size at completion should be correct and once aliqueit is running, the size should update correctly within a few seconds.

Just a note to announce version [URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]20100522[/URL].

The most noticable changes are the addition of information when aliqueit finishes early due to an error in the elf file, and the addition of a verification routine.

By setting the size to work to, to the value 0, you can now have AliWin retrieve whole elfs from the db and verify them. The simple lines:
[code]
0 1053228, 1053384, 1053528, 1053570, 1053642, 1053792
82 1055430, 1055490
0 1053822, 1053870, 1053918, 1053936
[/code]
placed in the Alinum.txt file, will now tell AliWin to verify the first six, take the next two to 82 digits and then verify the last four. The verifications are added to a file called "ASValidate.txt" and saved in the same directory as AliWin. For correct accuracy, any local copies of the elfs should be removed first, because they will probably not include the last (incomplete) line, as the version from the db will.

I've been trying version 20100523 and notice a few things:

- 74 curves with B1=11K are ran, even though the sequence is larger than the cutoff
- If you stop aliqueit and press the "Clear List" button, it doesn't change back to "Enter ## #"
- Why is the format in the GUI ###### ## and in alinum.txt ## ######? The first one is more intuitive.
- If an empty alinum.txt exits, aliwin has just a blank screen and all temp fiules need to be removed to get the full GUI back
- Can you remove the annoying "As-Is-Acceptance query? At least after accepting it the first time.
- Can you remove / make configurable the warning on exit?
- If a number is finished running, the "clear list" button gives an error about a wrong format, while the list isn't cleared.

[quote=smh;215966]I've been trying version 20100523 and notice a few things:[/quote]
Thank you for the excellent feedback!
[quote]- 74 curves with B1=11K are ran, even though the sequence is larger than the cutoff [/quote]-There is a delay of up to 5 seconds from completing a line to AliWin confirming the size has been reached. Is this when the 74 curves were run? I can probably reduce this, but the more often I check, the more disk access occurs. I'm not sure of a good balance.[quote]- If you stop aliqueit and press the "Clear List" button, it doesn't change back to "Enter ## #"[/quote]-If there is an alinum.txt file, it tries to use it. Are you suggesting that once the numbers in the list are exhausted, that clearing the list should allow manual entry? That seems like a good idea. I was going under the idea that if an alinum.txt file was being used, it would simply be edited to continue. In rereading this, I am now understanding that you might mean when a manual enty has been run, it doesn't allow for a subsequent manual entry. I'll study all of this.[quote]- Why is the format in the GUI ###### ## and in alinum.txt ## ######? The first one is more intuitive.[/quote]-alinum.txt allows you to enter the size once and a series of all the numbers to take to that size. It seemed simpler to set it up that way, and it made alinum.txt identical for AliPerl and AliWin. As you noted, the GUI version is more intuitive and that is why it is set up that way for single entry.[quote]- If an empty alinum.txt exits, aliwin has just a blank screen and all temp fiules need to be removed to get the full GUI back[/quote]-I will "fix" this. It should check for validity instead of just file existence.[quote]- Can you remove the annoying "As-Is-Acceptance query? At least after accepting it the first time.[/quote]-I like the idea of supressing the acceptance after you choose it once. I can add a switch to the cfg file.[quote]- Can you remove / make configurable the warning on exit?[/quote]-Are you suggesting getting rid of the exit query all together? How about if an exit is called while aliqueit is running. Maybe then I could query?[quote]- If a number is finished running, the "clear list" button gives an error about a wrong format, while the list isn't cleared.[/quote]-I'll check this out and see what is going on.

Thanks again for the review. I will post again when I get a chance to work on it.

I have made some changes based on feedback from smh. The version is now .[URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]20100524[/URL].

The check is now made every three seconds instead of five while aliqueit is running. If I can figure out how to get FileSystemWatcher to work, I will change to checking for log file activity.

I have reworked the "Enter ## #" and "Clear list" routines somewhat. Let me know if there is still trouble.

The "AS-IS" message only needs to be accepted once now (unless there is a change or deletion in the AliWin.cfg file).

The "Quit query" now only shows if Aliqueit is running when you try to close AliWin.

I have updated to .[URL="http://www.starreloaders.com/edhall/AliWin/AliWin.html"]20100526[/URL].

This was because the previous version which removed the closing prompt, if aliqueit isn't running, also removed the configuration save.

In light of the [URL="http://www.mersenneforum.org/showthread.php?t=11618&page=15#358"]recent changes to Aliqueit[/URL], I am rewriting AliWin (and working on a linux version). I have a few comments/questions:

1. I'm considering that if you are using AliWin, it is to work on sequences to a desired size as listed in Alinum.txt, therefore I am using -d <max_digits> as the norm without providing a choice. (There is one exception - using 0 as size to verify .elfs.)

2. I am considering also that if you wish to use the -c <max_cofactor> option, -b is assumed. Is there any reason to consider OR rather than AND?

3. I am adding the capability to choose a percentage of the digit size, as well as a straight value for the cofactor. IOW, you can choose 80% and the max_cofactor size will track with the max_digits size, e.g. if your first number is to 100 digits and your second is to 110, the cofactor sizes will be 80 and 88, respectively.

4. Is -m <max_ecm_level> designed to be used with -d -c -b, or different?

5. Is there a need for the switches to be in a particular order? Would the following be appropriate: "aliqueit -d 110 -b -c 88 -e -p 977880"

6. Should I still offer the current version of AliWin, or completely step to the new version? The new version will only work with Aliqueit 1.10 and forward. I am prepared to call this one AliWin2, if there might be confusion between versions.

7. Would there be any reason to start a new thread, or would this one suffice for the newer version of AliWin?

Any and all comments/answers are requested and welcome. . .

The ordering of the switches doesn't matter.

-m and using 'or' are both kind of specialized, but I have used them. If you primarily want to use the cofactor of a certain level (say get your sequences up to cofactors greater than 80), then there is the difficulty that the ecm step can take days. To avoid this you use the 'or' option so that for example, if a sequence is to 120 digits, you skip it and do no work. Or you can use the -m to skip the slower levels of ecm.

Another way to think of it: With the 'and' option you always do full ecm. With the 'or' option you don't do any ecm on very large sequences (above the number of digits).

I think I have a handle on what you explained, but not totally sure.

I have a version of AliWin2.exe in testing right now. If you (or anyone) want(s) to check it out, it can be downloaded from [URL="http://www.starreloaders.com/edhall/AliWin/AliWin2.exe"]here[/URL]. I will eventually provide it its own page and include the source file, but this should give a chance to test it. BTW, if the version of Aliqueit isn't 1.10, then "Run aliqueit" flashes for a second and then reports the number as finished. What's actually happening is that (the older) Aliqueit doesn't recognize the -d switch and closes the window before allowing a chance to read the message.

Ah, a last question: Is (m * 5 + 15 = digits) correct for all the values for <max_ecm_level>?

Thanks.

Is Aliqueit still using the "old" DB? Are the "old" and "new" DB synchronized?

Aliqueit.exe (the new V1.10, too) uses the old factorDB for uploading seqs to [url]http://factorization.ath.cx/[/url] -> old address hard-coded!

And I think Syd have to synchronize the new DB with new factors of the old DB manually initiated!

[quote=EdH;228294

Ah, a last question: Is (m * 5 + 15 = digits) correct for all the values for <max_ecm_level>?

Thanks.[/quote]

Ya, that looks right. You might also want to warn or enforce the rule that if you use -m then there is no -b flag and -c is also included and that c <= 3*(m*5+15). The reason is that otherwise you will get cofactors that have not gotten their full ecm because -m will stop it too early. In other words, if m=1 then c<=60, if m=2 then c<=75, if m=3 then c<= 90.

So for example, if you used:
-m 2 -c 100 then a 101 digit number would only be checked for factors up to 25 digits and a 99 digit cofactor would get gnfs when it could easily have a factor less than 30 digits that would normally be found.

Also:
-m 2 -c 75 -d 120 -b could have a 119 digit number and a 118 digit cofactor that would get gnfs when again it could have a 30 digit factor that should have been found. The -b means we would do the gnfs on the 118 cofactor because -d 120 wasn't reached.

-----------
The 3 in 3*(m*5+15) comes from the approximate rule that you want to look for factors up to 1/3 the size of the cofactor.

-----------
BTW: The exact meaning is the number m is the iterations it allows in the following array (found in the code for aliqueit):

[code]
int run_ecm_big( string input_number, vector<mpz_class> & new_factors ) {
int ecm_settings[][3] = {
{ 20, 11000, 74 },
{ 25, 50000, 214 },
{ 30, 250000, 430 },
{ 35, 1000000, 904 },
{ 40, 3000000, 2350 },
{ 45, 11000000, 4480 },
{ 50, 43000000, 7553 },
{ 55, 110000000, 17769 },
{ 60, 260000000, 42017 },
{ 65, 850000000, 69408 }, //quick, someone find a way for this to be useful!
};
[/code]

I'm trying to get an understanding here. I think I almost have it, but something seems somewhat unclear still.

To put this in "AliWin" terms, being driven by the -d option primarily, should I limit the low end of the available -m value? IOW, should I allow only -m levels driven by -d, e.g. for a 110 digit number, -m must be > 4, for a 120, -m must be > 5, etc.?

I also wondered about the upper bound for -m. That appears to be 10. I should limit -m inputs to the value between the formula and 10, then?

Thanks for the additional info.

Currently, I am having other issues with AliWin due to the db changes. None of the automatic retrieval and posting is functioning. In part, due to the new message (ad for the new db) that has been tacked on the front of the sequence data from the old db and my ignorance in knowing how to retrieve it from the new db. So right now I'm having to do retrieval and posting manually.

[quote=EdH;229111]I'm trying to get an understanding here. I think I almost have it, but something seems somewhat unclear still.

To put this in "AliWin" terms, being driven by the -d option primarily, should I limit the low end of the available -m value? IOW, should I allow only -m levels driven by -d, e.g. for a 110 digit number, -m must be > 4, for a 120, -m must be > 5, etc.?

I also wondered about the upper bound for -m. That appears to be 10. I should limit -m inputs to the value between the formula and 10, then?

Thanks for the additional info.

Currently, I am having other issues with AliWin due to the db changes. None of the automatic retrieval and posting is functioning. In part, due to the new message (ad for the new db) that has been tacked on the front of the sequence data from the old db and my ignorance in knowing how to retrieve it from the new db. So right now I'm having to do retrieval and posting manually.[/quote]

The easiest thing is to not set m at all because aliqueit handles it automatically. It will only do as much ecm as is needed.

Only if you allow m to be settable, then you want to limit things. Using the -m switch with the -d switch (only) isn't useful at all. It is primarily so that very large cofactors don't run full ecm - however with the -d flag the size of the cofactor is already limited by the max digits.

The main use of the -m is with the -c flag. If I ran aliqueit -c 90 4788 then it could take weeks for a 170 digit cofactor to do full ecm and stop and the user may not want to do that. aliqueit -d 90 4788 would stop right away of course because 4788 is over 90 digits.

So I would only include -m in aliwin if you allow for setting the -c without setting the -d. If the current version works with -d then simply don't worry about -m (don't allow it to be set and don't use it to call aliqueit).

[quote=Greebley;229169]The easiest thing is to not set m at all because aliqueit handles it automatically. It will only do as much ecm as is needed. . . If the current version works with -d then simply don't worry about -m (don't allow it to be set and don't use it to call aliqueit).[/quote]
AliWin currently expects -d to be set either by direct entry or from the Alinum.txt file. Based on your message, I'll leave -m out of the options, at least for now. I'll remove it the next chance I get to work with the source.

I'm trying to get Aliwin2 working and everything's good except GGNFS. After triple-checking the installation directions on the website, I still get this error after msieve starts:

error (line 104): CUDA_ERROR_FILE_NOT_FOUND
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
WARNING: gnfs failed to find a factor. This really shouldn't happen.
I'll just run ecm till the end of time or a factor turns up...
Let's hope you don't run out of disk space before either of those.

I'm trying to use the latest version of msieve with GPU support. The odd thing is I've got a separate installation of GGNFS already up and running, I just can't get the ggnfs_cmd line working (it's currently:

ggnfs_cmd = C:\Program Files\Python\python "C:\MathWork\aliqueit\factmsieve.py"

Any suggestions?

Thanks!

At first glance, my thoughts are to try "USE_CUDA = True" as False to see if it works that way before trying to run CUDA, or maybe the path to msieve is incorrect. If you do change the True to False in factmsieve.py (line 72), be sure of the capital - "false" will not work. Let me know how it runs.

Also, as a side note, the current version for AliWin2 is 20101118. The earlier one has a small bug due to leaving a troubleshooting note set. The bug would cause the cofactor size to change to 0 when Auto Send was invoked.

Otherwise, Brian Gladman (.py script) and/or JasonP (msieve) might be able to help. (I have left a message in the factmsieve.py thread.)

Update:

In reviewing this further, I think the trouble is with the slashes. All the slashes need to be forward instead of back slashes. I need to change that on the page.

Let me know if that helps.

Further info:

In [URL="http://mersenneforum.org/showpost.php?p=238105&postcount=518"]the other thread[/URL], I received this from WraithX:

"The error you received was because of the space between Program and Files in the above command line. So, you might first want to try putting quotes (") around the python part of your line, like so:"[code]
ggnfs_cmd = C:\Program Files\Python\python "C:\MathWork\aliqueit\factmsieve.py"
[/code]smh also suggested:
[code]
Or use the old 8.3 style, like c:\progra~1\
[/code]Sorry I didn't notice this. . . I guess I was too tied up and hurried with other things to properly review your post.

[QUOTE=EdH;238101]
"The error you received was because of the space between Program and Files in the above command line. So, you might first want to try putting quotes (") around the python part of your line, like so:"[code]
ggnfs_cmd = C:\Program Files\Python\python "C:\MathWork\aliqueit\factmsieve.py"[/QUOTE]

The quotes are around the wrong section in your post.

[QUOTE=10metreh;238124]The quotes are around the wrong section in your post.[/QUOTE]
Indeed it is! I copied the OP's section instead of WraithX's, which was:
[code]
ggnfs_cmd = "C:\Program Files\Python\python" "C:\MathWork\aliqueit\factmsieve.py"
[/code]I hope I did better this time, but today seems to be amiss here for me.:sad:
Thanks for trying to help keep me straight.

Ok, I got GGNFS to launch and everything works fine but I'm still getting the CUDA error. On the other thread, this was mentioned:

msieve with CUDA support looks for a few *.ptx files in the current working directory; the CUDA runtime pops out this error when it doesn't find them. Either the files aren't there or the current directory as specified by python is not what you think it is.

Does Aliwin work with msieve with GPU support? Do I need to change some other setting for it to find the ptx files?

Thanks again for a great application!

[QUOTE=Mr. Odd;238179]Ok, I got GGNFS to launch and everything works fine but I'm still getting the CUDA error. On the other thread, this was mentioned:

msieve with CUDA support looks for a few *.ptx files in the current working directory; the CUDA runtime pops out this error when it doesn't find them. Either the files aren't there or the current directory as specified by python is not what you think it is.

Does Aliwin work with msieve with GPU support? Do I need to change some other setting for it to find the ptx files?

Thanks again for a great application![/QUOTE]
Thanks for the Thanks.:smile:

I see no reason AliWin shouldn't work with GPU support, but I have never tried it. Here is the direction I would take:

In my basic setup, I suggest copying the msieve program into the ggnfs location and renaming it to just msieve.exe. In the case of CUDA, I would additionally copy all the *.ptx files and the fermi directory with all its *.ptx files into the same location as the msieve.exe program.

By latest version, are you referring to compiling the source from the repository, or the latest compiled msieve.exe? In either case, I would copy all the *.ptx files from the latest msieve###_gpu.zip file available to you and see if that helps it run.

Good luck with it. Let me know how things turn out.

I'm running the latest compiled version of Aliwin. And I've got the ptx files along with the latest msieve with gpu support in the ggnfs directory. What I noticed is that you set up a new ggnfs_(n) directory for each new (n). Perhaps it's not finding the ptx files in that working directory?

The new ggnfs file is set up by Aliqueit each time it runs a new gnfs composite. That shouldn't affect how msieve runs. It should still work out of its home directory. We might have to check with JasonP to verify, though.

Let's give the following a try:

Create a folder called msieve in the Mathwork folder.

Extract all the files from msieve147_gpu.zip into the new msieve folder.

There should be ten *.ptx files, msieve147_gpu.exe and a folder called fermi which has ten more *.ptx files.

Rename msieve147_gpu.exe to msieve.exe

In Aliqueit.ini, make the following change:
[code]
//Name (and path, if needed) of your msieve executable.
msieve_cmd = C:/Mathwork/msieve/msieve.exe
[/code]In factmsieve.py, make the following change:
[code]
MSIEVE_PATH = 'C:/Mathwork/msieve/'
[/code]See if that makes sense and let me know how it turns out.

Are you familiar with [URL="http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx"]Process Monitor[/URL]? This makes it easy to see where msieve is looking for the files.

Also, note that if you have a graphics card with a Fermi GPU, overwrite the .ptx files with the ones in the fermi subdirectory, they do make poly searching noticeably faster. Yes, in the future msieve should figure out for itself which ptx files to use.