[QUOTE=miklin;175488]Hello, whether Respected SYD.А it is possible as not be to receive processing files php and base sql. For installation on the server.

Yours faithfully Sergey Miklin.[/QUOTE]

No, its closed-source-"spaghetti"-code.

[QUOTE=akruppa;175775]Andi47 pointed out that 7771 curves with B1=43M and B2=4.3G are listed under my name for Aliquot sequence 4788 index 2409 ([url]http://factorization.ath.cx/search.php?id=39375746[/url]), but I didn't do them. Is this an error in the DB, or did someone report curves under my name?

Alex[/QUOTE]

Hm. Just looked it up in the logs, it seems like these curves were reported. Maybe you reported them for some other number and a bug sent them over?

[QUOTE=10metreh;175842]Whoever it was wanted to get on with their own number, and they put in fake curves. I once did this for another reason (because one person was persistently babysitting their number), but putting in a fake name makes it even worse.

Maybe we should have to register in order to submit curves?[/QUOTE]

What do the others think? I could put up some register-email-validation-code thing, but is it really necessary?

[QUOTE=henryzz;176211][code]#0: 120 curves with B1: 120000, B2: 90000000 on C118
#0: 120 curves with B1: 120000, B2: 90000000 on C117

.....

#0: 1 curves with B1: 3000000, B2: 7000000000 on C225[/code]
all of these are one digit lower than on [url]http://factorization.ath.cx/workerstatus.php[/url]
i am using the precompiled binary[/QUOTE]

Fixed :smile: Together with the "stops-and-does-nothing"-bug. Use this link:
[url]http://factorization.ath.cx/worker.tar.bz2[/url]

Maybe it already compiles for windows, just haven't tried.

[QUOTE=Syd;176270]
Fixed :smile: Together with the "stops-and-does-nothing"-bug. Use this link:
[url]http://factorization.ath.cx/worker.tar.bz2[/url]

Maybe it already compiles for windows, just haven't tried.[/QUOTE]

Well, it didn't compile with mingw, it is currently using several "unix" include files/functions that windows doesn't have, and if it does have them, they are in different places. (I may research how to change this, if you would like me to look, Syd?)

However, it compiles just fine in cygwin. I am running it right now. I think it briefly showed up in the workers queue as #100 "Testing...", but I'm not sure if that was me or not. BTW, I had to change the makefile slightly to get it to compile in cygwin. I had to move the -lgmp to the end of the line to get it to compile for me.

edit: Also, (I ask because I've looked at the code) do I have to have ecm or msieve in the same directory (or "in the path") in order for this worker to "work"? This may be why it has 0% cpu utilization. Hmmm... let me put those binaries in there and see what happens. (brb)

How do I know if it's working or not? It has printed a bunch of lines like:
#0 120 curves with B1: 120000, B2: 90000000 on C118
I see the C118 change from time to time to C117 or C116. I guess this is part of the testing process? To make sure my machine is returning correct results?

Oops, and now it just segfaulted. Would the stackdump file be useful to you Syd? The whole time it was running it was only using 5MB of memory and 0% cpu utilization. I'm running it again to see if that happens again. Should I also test it with multiple threads? Right now I'm just starting it with ./worker.exe and letting it run. I'll let you know if anything happens to the current run. Let me know what you think of my above questions.

edit: Also (from looking at the code), do I need to have an ecm or msieve binary in the same folder (or in my path) so that the worker can find them? This may be why the worker is only at 0% cpu utilization. Hmmm... I'll put the binaries in there now and see what happens.

edit2: Aha! It has now spawned an ecm process and it has shown up on the worker status page. If anyone has cygwin installed you can use the binary I am attaching. FYI, you will need to get ecm and/or msieve and put them in the same folder you run this binary from. Jeff Gilchrist has compiled those for Windows and you can find them [URL="http://gilchrist.ca/jeff/factoring/"]HERE[/URL].

[QUOTE=WraithX;176279]Well, it didn't compile with mingw, it is currently using several "unix" include files/functions that windows doesn't have, and if it does have them, they are in different places. (I may research how to change this, if you would like me to look, Syd?)
[/QUOTE]

I guess its select and execlp? Cygwin should be fine.


[QUOTE=WraithX;176279]
However, it compiles just fine in cygwin. I am running it right now. I think it briefly showed up in the workers queue as #100 "Testing...", but I'm not sure if that was me or not. BTW, I had to change the makefile slightly to get it to compile in cygwin. I had to move the -lgmp to the end of the line to get it to compile for me.

edit: Also, (I ask because I've looked at the code) do I have to have ecm or msieve in the same directory (or "in the path") in order for this worker to "work"? This may be why it has 0% cpu utilization. Hmmm... let me put those binaries in there and see what happens. (brb)
[/QUOTE]

Great work!
I guess it has to be in $PATH on windows, this is how ecm is executed:
execlp("ecm","ecm","-one","-c",curves,b1,b2,NULL)

maybe its "ecm.exe" on windows?

[QUOTE=WraithX;176279]

How do I know if it's working or not? It has printed a bunch of lines like:
#0 120 curves with B1: 120000, B2: 90000000 on C118
I see the C118 change from time to time to C117 or C116. I guess this is part of the testing process? To make sure my machine is returning correct results?
[/QUOTE]

This is the initial testing work (B1=120000), seems like your client fails the tests and is disconnected afterwards. Maybe cause it cant find the ecm executable?

[QUOTE=WraithX;176279]
Oops, and now it just segfaulted. Would the stackdump file be useful to you Syd? The whole time it was running it was only using 5MB of memory and 0% cpu utilization. I'm running it again to see if that happens again. Should I also test it with multiple threads? Right now I'm just starting it with ./worker.exe and letting it run. I'll let you know if anything happens to the current run. Let me know what you think of my above questions.
[/QUOTE]

Just starting it should be fine. Maybe give your worker a name so you can see what its doing on the status page.


edit:
Nice one! Its running, passed all tests and does some "real" work now!

[QUOTE=Syd;176284]
edit:
Nice one! Its running, passed all tests and does some "real" work now![/QUOTE]

Does it hurt to kill it in the middle of a curve? Like if I want to give it a name or use a different number of threads?

[QUOTE=WraithX;176285]Does it hurt to kill it in the middle of a curve? Like if I want to give it a name or use a different number of threads?[/QUOTE]

You can kill it any time. Just the current curve is discarded.

the WIN-version seems to run ok. with cygwin1.dll (1873811 bytes), ecm.exe and msieve.exe in same folder!
just now only ECM-work done.

[QUOTE=Syd;176270]
Hm. Just looked it up in the logs, it seems like these curves were reported. Maybe you reported them for some other number and a bug sent them over?
[/QUOTE]

I reported a few curves for Aliq276.1635 but none with the B1 or B2 or count reported for Aliq4788.2409.

Alex

I Have started the Windows worker.exe and it looks ok :maybeso:

i think allowing windows workers has worked a treat
we now have several external workers

Yes, this is good news!

hmmmm... the windows binary doesn't work for me - can't start application, cygwin1.dll not found.

Edit: downloaded cygwin1.dll and got it go run now, but...

it sayd "using 4 cpus" (?? this PC only has 1 cpu)

are there any options to set the number of cpus and to give a name to the worker?