You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(53) |
Sep
(93) |
Oct
(16) |
Nov
(15) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(32) |
Feb
(37) |
Mar
(13) |
Apr
(19) |
May
(124) |
Jun
(119) |
Jul
(2) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
2004 |
Jan
(13) |
Feb
(13) |
Mar
(5) |
Apr
(7) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(5) |
Nov
(29) |
Dec
(16) |
2009 |
Jan
(33) |
Feb
(3) |
Mar
(4) |
Apr
(6) |
May
(4) |
Jun
(2) |
Jul
(26) |
Aug
(6) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
(19) |
2010 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(32) |
Jul
(13) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(4) |
Mar
|
Apr
(11) |
May
(43) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ike D. <ike...@gm...> - 2017-06-11 19:49:44
|
Op zaterdag 10 juni 2017 13:54:45 CEST schreef Rhialto: > Stupid sourceforge wants me to "reconfirm" my mailing list subscriptions, > using a stupid javascript-laden webpage with captchas that does not work. > I've lost a good part of an hour now on that crap and it still doesn't > work. > > I've had it with sourceforge. We should get rid of it. Immediately. > > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X > \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly. Almost everything is on github. I could scrape the current site and move it like that to github too. -- Ike |
From: Rhialto <rh...@fa...> - 2017-06-10 17:17:14
|
On Sat 10 Jun 2017 at 19:05:13 +0200, Tristan Miller wrote: > I'm a bit surprised y'all didn't drop it a couple years ago when they > were found to be bundling adware with installer downloads. I think there was a discussion about it then as well. It is also when I started to make a private mirror of the svn repo for VICE, just in case it would ne needed. (I'm updating it by hand so it will always be a bit behind though). > Tristan -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly. |
From: Rhialto <rh...@fa...> - 2017-06-10 12:12:32
|
Stupid sourceforge wants me to "reconfirm" my mailing list subscriptions, using a stupid javascript-laden webpage with captchas that does not work. I've lost a good part of an hour now on that crap and it still doesn't work. I've had it with sourceforge. We should get rid of it. Immediately. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly. |
From: Gary S. <gse...@gm...> - 2016-04-07 23:56:20
|
I want to say "Thank you"* to all who have contributed* to developing this great software! Gary Sellars On Tue, Apr 5, 2016 at 4:37 PM, Ike Devolder <ike...@gm...> wrote: > On Tue, Apr 05, 2016 at 02:59:03PM +0000, Przemek Kowalczyk wrote: > > Is the latest release 0.6.13 or 0.6.14? I think the "Latest Release" > label > > is confusing on this page > https://github.com/Parchive/par2cmdline/releases > > > > Its 0.6.14, I have no idea why github still marks 0.6.13 as latest. > > -- > Ike > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Parchive-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parchive-devel > > -- -- http://www.cleareyesight.info/ <<- Remove your glasses & fix your eyes http://healingrooms.com/?src=content&cid=4 Most people don't let the Bible interfere with their theology. -- Andrew Wommack <http://www.awmi.net/extra/audio> The truth about Islam --> <http://www.youtube.com/watch?v=Ib9rofXQl6w <http://www.youtube.com/watch?v=Ib9rofXQl6w>> Do your own research on Smart Meter radiation. As established by a Court in Santa Cruz, California, it is harmful and is 50 to 480 times even more powerful/dangerous than a cell phone! They will also be used as a monitoring device and will tell the government when you're asleep and when you're showering. Consider the potential harm to you and your loved ones. |
From: Ike D. <ike...@gm...> - 2016-04-05 21:37:37
|
On Tue, Apr 05, 2016 at 02:59:03PM +0000, Przemek Kowalczyk wrote: > Is the latest release 0.6.13 or 0.6.14? I think the "Latest Release" label > is confusing on this page https://github.com/Parchive/par2cmdline/releases > Its 0.6.14, I have no idea why github still marks 0.6.13 as latest. -- Ike |
From: Przemek K. <prz...@gm...> - 2016-04-05 14:59:24
|
Is the latest release 0.6.13 or 0.6.14? I think the "Latest Release" label is confusing on this page https://github.com/Parchive/par2cmdline/releases On Tue, Oct 20, 2015 at 12:41 AM Ike Devolder <ike...@gm...> wrote: > On Mon, Oct 19, 2015 at 07:37:13PM -0600, Robin Laing wrote: > > Hello, > > > > I just wanted to say that the latest Github par2cmd line repaired a set > > of files that the Fedora 22 release version wouldn't repair. I had to > > use the -N option but it did work. > > > > I just wanted to say thank you. > > > > Robin Laing > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Parchive-devel mailing list > > Par...@li... > > https://lists.sourceforge.net/lists/listinfo/parchive-devel > > I'm glad you got your files fixed. > > And thanks for the thank you to everyone who ever contributed to par2. > > -- > Ike > > ------------------------------------------------------------------------------ > _______________________________________________ > Parchive-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parchive-devel > |
From: Ike D. <ike...@gm...> - 2015-10-20 04:41:40
|
On Mon, Oct 19, 2015 at 07:37:13PM -0600, Robin Laing wrote: > Hello, > > I just wanted to say that the latest Github par2cmd line repaired a set > of files that the Fedora 22 release version wouldn't repair. I had to > use the -N option but it did work. > > I just wanted to say thank you. > > Robin Laing > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Parchive-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parchive-devel I'm glad you got your files fixed. And thanks for the thank you to everyone who ever contributed to par2. -- Ike |
From: Robin L. <MeSat@TelusPlanet.net> - 2015-10-20 01:50:51
|
Hello, I just wanted to say that the latest Github par2cmd line repaired a set of files that the Fedora 22 release version wouldn't repair. I had to use the -N option but it did work. I just wanted to say thank you. Robin Laing |
From: Peter C. <pe...@co...> - 2015-07-31 05:19:58
|
On Thu, Jul 30, 2015 at 08:32:56PM -0600, Ace Olszowka wrote: > please make sure that a "reference" implementation is kept in fairly > Portable C. Yes, of course! It needs to work on all platforms, so the pure C version needs to be there. I got some responses to http://stackoverflow.com/questions/31734263/write-x86-asm-functions-portably-win-linux-osx-without-a-build-depend-on-yasm I'm inclined to just use masm syntax, and have ./configure search for nasm or yasm. (unless I can figure out a way to get gas to assemble it, maybe with CPP macros.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC |
From: Ace O. <aol...@gm...> - 2015-07-31 02:33:03
|
Too low level for me to make a meaningful comment on the actual implementation, I just wanted to chime in and say that: If you do choose to provide a super hand optimized Assembly Routine for some functionality please make sure that a "reference" implementation is kept in fairly Portable C. I think this same sentiment has been voiced on the mailing list before, but probably bears repeating. Thank you for the work you've done on this, I can tell that you've put a lot of thought and effort into it and as an end user I appreciate it greatly! On Thu, Jul 30, 2015 at 2:43 PM, Peter Cordes <pe...@co...> wrote: > See my prev message about the specific asm. > > gcc doesn't always generate good code from intrinsics, so I wrote some > of my routines directly in asm. The question is how to include these > functions in a way that they can be used by multiple compilers on > Linux, Windows, and OS X. > > Inline asm is not very portable, so defining a function in a separate > file is the way to go. > > If I use AT&T syntax, then it can build with gcc / clang / icc, but > IDK anything about MSVC. Do we care about MSVC? > > The GNU assembler supports Intel syntax for opcodes, but it would > still use AT&T-style assembler directives, not NASM / YASM style. > (e.g. .align rather than align). > > > I'm not sure there's a clean solution without introducing a > build-dependency on yasm (http://yasm.tortall.net/). If we did use > yasm for asm code, that would work everywhere. x264 uses yasm. > > However, most people have gcc but not yasm installed. > > So, thoughts on having asm speedups in the par2 mainline? I'm just > talking about an alternative version of rs_process(), so it shouldn't > impact code clarity. > > There are significant speed gains here. I think something like a 50% > speedup over C. > > I'm going to post a question on stackoverflow about portable asm, and > see if there are any good ways to make it portable without introducing > a dependency on yasm, and without keeping two versions of the same > code in sync. (One MASM syntax for MSVC, which I think it can handle > natively, and one AT&T / gas syntax for everything else.) > > -- > #define X(x,y) x##y > Peter Cordes ; e-mail: X(peter@cor , des.ca) > > "The gods confound the man who first found out how to distinguish the > hours! > Confound him, too, who in this place set up a sundial, to cut and hack > my day so wretchedly into small pieces!" -- Plautus, 200 BC > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iLwEAQEIAAYFAlW6jIIACgkQBaSaEuRa5FPNtgT+PaWjRga/Ii5yqCTwEurzdoVj > b9R6JapQMmLU6o2/PlUyabc9I8nC+1hTkhM4DR2BiwuaOLuBgfINeR+N6kNyWSP1 > acOmqbNcLd0pFcULjPgSLa0p7tt/fiytikeL6iSC7Vk8TradJ7bis80k2afhQRRr > 38vi+qI24iihGLuLVblv2gScreXFGsA7X9CbH+qrwN1kMBGQEROHSxoXct0BKg== > =FKXV > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Parchive-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parchive-devel > > |
From: Peter C. <pe...@co...> - 2015-07-30 20:43:52
|
See my prev message about the specific asm. gcc doesn't always generate good code from intrinsics, so I wrote some of my routines directly in asm. The question is how to include these functions in a way that they can be used by multiple compilers on Linux, Windows, and OS X. Inline asm is not very portable, so defining a function in a separate file is the way to go. If I use AT&T syntax, then it can build with gcc / clang / icc, but IDK anything about MSVC. Do we care about MSVC? The GNU assembler supports Intel syntax for opcodes, but it would still use AT&T-style assembler directives, not NASM / YASM style. (e.g. .align rather than align). I'm not sure there's a clean solution without introducing a build-dependency on yasm (http://yasm.tortall.net/). If we did use yasm for asm code, that would work everywhere. x264 uses yasm. However, most people have gcc but not yasm installed. So, thoughts on having asm speedups in the par2 mainline? I'm just talking about an alternative version of rs_process(), so it shouldn't impact code clarity. There are significant speed gains here. I think something like a 50% speedup over C. I'm going to post a question on stackoverflow about portable asm, and see if there are any good ways to make it portable without introducing a dependency on yasm, and without keeping two versions of the same code in sync. (One MASM syntax for MSVC, which I think it can handle natively, and one AT&T / gas syntax for everything else.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC |
From: Peter C. <pe...@co...> - 2015-07-30 20:33:27
|
I've been playing around with some x86 asm speedups for rs_process. I'll send another mail in a sec about practical considerations for merging this into par2 mainline. https://github.com/pcordes/par2-asm-experiments Compile with: gcc -DIACA_MARKS_OFF -o rs-asmbench -g -Wall -march=native -funroll-loops -O3 -std=gnu11 main.c process-purec.c intrin-nolut.c reedsolomon-x86_64-mmx.s reedsolomon-x86_64-mmx-orig.s asm-avx2-vgatherdd.s intrin-pinsrw.c asm-pinsrw*.s (I'm lazy and didn't make a Makefile for it.) That git repo has some implementations, and a little benchmark driver that runs various routines in a loop and prints RDTSC counts for each. (Take the minimum: RDTSC counts at constant rate, even if your CPU isn't running at max frequency. Also, interrupts / other events can cause a glitch in one run.) Some of the functions aren't don't actually give correct results, I just wanted to see if they ran any faster when a certian bottleneck was removed. (e.g. pinsrw-nodep uses different registers for successive inserts, to see if the dependency chain was an issue.) The interesting functions are: pinsrw128: my best so far, on Sandybridge. see below orig-MMX: maybe fastest on Nehalem. (code from par2tbb) nolut AVX: see below AVX2 vgather: uses VPGATHERDD. Might be close to pinsrw128 on Broadwell. Others are there just as experiments, and for something to do while the CPU ramps up to full speed. ***************** My best general-purpose version so far uses SSE2 PINSRW: https://github.com/pcordes/par2-asm-experiments/blob/master/asm-pinsrw.s which is about 16% faster than the MMX punpck code from par2tbb: https://github.com/pcordes/par2-cleanhistory/blob/par2tbb-upstream/reedsolomon-x86_64-mmx.s Tested on Intel Sandybridge (i5-2500k) no hyperthreading, single-threaded. Last I tested, it was slower on Nehalem. The loop doesn't quite fit in the loop buffer, so decode is a bottleneck on Nehalem. par2 should choose which rs_process function to use, based on the CPU. On Nehalem (or CPUs without AVX), it should probably choose the MMX version. ********************* When the GF16 factor to multiply a source block has few significant bits, the straightforward non-LUT Peasant's Algorithm (https://en.wikipedia.org/wiki/Finite_field_arithmetic#Multiplication) actually wins. https://github.com/pcordes/par2-asm-experiments/blob/master/intrin-nolut.c Checking how many leading zeroes there are in factor is trivial (one instruction), so dispatching based on a break-even threshold for that is the way to go. The nolut routine, with factor having a full 16 significant bits performs like so on SnB / Haswell CPUs: * AVX: theoretical throughput of 3.33c per source byte, in practice 3.35c (unless that number is off because RDTSC's clock was running slower than the actual CPU turbo frequency.) * AVX2: 1.66c / source byte. Twice as fast: same code, but twice as wide. Memory prefetch should still easily be able to keep up. * AVX512BW: 0.666c / source byte. (more than twice as fast, since masked operations save 2 of 10 uops (instructions) in the inner loop.) Available on Xeon-only Skylake, and then hopefully on desktop/laptop CPUs in the generation after that. This is compared to ~1c / source byte for my pinsrw loop. So until AVX512, the standard LUT version is fastest (when factor has most of its bits set). ****************************** I never really tried to implement Alexander Wegel's 256b LUT for 4-bit halves. I think it might be viable with separate 128b LUTs, and shuffling or masking to combine the results, since before the LUT, some elements were having their high bits set. Anyway, it looked like a lot of shuffling needed. It's worth looking into with AVX2. ****************************** I did make a version that uses Intel's AVX2 gather instruction to do the lookup. It takes about 1.7x as much time as the PINSRW loop, on Haswell. Broadwell is supposed to speed up gather by a factor of about 1.6, so it's going to only a bit of a loss to use it on Broadwell. If Skylake speeds it up any more, it might be worth looking at. (I'd like to see benchmark output from anyone that can run this on a broadwell CPU.) https://github.com/pcordes/par2-asm-experiments/blob/master/asm-avx2-vgatherdd.s -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC |
From: Ike D. <ike...@gm...> - 2015-06-06 05:17:30
|
UPDATE: On Thu, May 21, 2015 at 08:58:21PM +0200, Ike Devolder wrote: > 1. create parchive organization on github (done) Done. > > 2. move the repo's over to that organization (par2cmdline is there > already) Done. > > 3. use cleaned up history for relevant repos and rename original imports > to ...-archived, or ...-imported In the long run. > > 4. move tickets from sourceforge to the correct repo's TODO. > > 5. make website available on parchive.github.io (now it has nothing ;)) > > 6. make sure the documents linked to from the website are on github > > 7. redirect most stuff from sourceforge to github > > users: > - confirm who is who to add to the parchive organization on github > - determine who will take the lead for specific repo's/things to be done > > unclear: > - forums, github does not do forums > - mailing lists, could just stay on sourceforge or migrate to something > else > > -- > Ike If there is someone who clould send me the tarball containing the files for the current 'parchive.sourceforge.net' website, please do. Also If you want to be added to the Parchive organization on github, drop me a note. -- Ike |
From: Ike D. <ike...@gm...> - 2015-05-29 05:02:32
|
On Fri, May 29, 2015 at 12:30:33PM +0900, Yutaka Sawada wrote: > Hello, Ike Devolder and SourceForge users. > I could not post mail on mailing-list for long. > > > If you are interested in contributing, > > you can state what your main interest is > > so we can organize who's doing what. > > I can compile par2cmdline binary for Windows OS. > Because most Windows users don't compile an application themselves, > available ready made binary is useful. > Is it possible to put it on Parchive's web-site ? > > At this time, I put my compiled binary on MultiPar's web-forum. > "https://www.livebusinesschat.com/smf/index.php?topic=5737.0" > Though my MultiPar doesn't use par2cmdline as PAR2 client, > some users wanted direct upgrade from old version par2cmdline. > > Best regards, > Yutaka Sawada > > > ------------------------------------------------------------------------------ > _______________________________________________ > Parchive-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parchive-devel Yutaka, That would be nice of you to do. I'll take the binary and upload it to github. When the website is transferred to gh-pages we can ofcourse add proper links and such to the windows binaries. -- Ike |
From: Yutaka S. <te...@ou...> - 2015-05-29 03:45:46
|
Hello, Ike Devolder and SourceForge users. I could not post mail on mailing-list for long. > If you are interested in contributing, > you can state what your main interest is > so we can organize who's doing what. I can compile par2cmdline binary for Windows OS. Because most Windows users don't compile an application themselves, available ready made binary is useful. Is it possible to put it on Parchive's web-site ? At this time, I put my compiled binary on MultiPar's web-forum. "https://www.livebusinesschat.com/smf/index.php?topic=5737.0" Though my MultiPar doesn't use par2cmdline as PAR2 client, some users wanted direct upgrade from old version par2cmdline. Best regards, Yutaka Sawada |
From: Ike D. <ike...@gm...> - 2015-05-27 19:26:56
|
par2cmdline 0.6.13 ================== BlackEagle (2): create test for #49 bump 0.6.13 Ike Devolder (1): Merge pull request #48 from jcfp/patch-1 PeterBClements (4): Fixes to enable "make distcheck" to work: Fix issue #50 (scan failure) / Correct fix for issue #31 (slow scan) Add test19 Merge pull request #51 from jcfp/master Sami Väisänen (1): Fix for #49 (Scanning extra files messes up verification) jcfp (3): add missing argument for the block-count option add -N / -S options to manpage Update commandline.cpp -- Ike |
From: Ike D. <ike...@gm...> - 2015-05-21 19:04:16
|
On Thu, May 21, 2015 at 08:58:21PM +0200, Ike Devolder wrote: > 1. create parchive organization on github (done) > > 2. move the repo's over to that organization (par2cmdline is there > already) > > 3. use cleaned up history for relevant repos and rename original imports > to ...-archived, or ...-imported > > 4. move tickets from sourceforge to the correct repo's > > 5. make website available on parchive.github.io (now it has nothing ;)) > > 6. make sure the documents linked to from the website are on github > > 7. redirect most stuff from sourceforge to github > > users: > - confirm who is who to add to the parchive organization on github > - determine who will take the lead for specific repo's/things to be done > > unclear: > - forums, github does not do forums > - mailing lists, could just stay on sourceforge or migrate to something > else > > -- > Ike The people who want to stay/get involved, please send me an email so I can invite you to the Parchive organization on github. If you are interested in contributing, you can state what your main interest is so we can organize who's doing what. - If you are interested to create a new or improve the current website, let me know. - If someone is interested in any part of Parchive let me know. - Someone who is interested to create something new related to parchive, welcome! -- Ike |
From: Ike D. <ike...@gm...> - 2015-05-21 18:58:33
|
1. create parchive organization on github (done) 2. move the repo's over to that organization (par2cmdline is there already) 3. use cleaned up history for relevant repos and rename original imports to ...-archived, or ...-imported 4. move tickets from sourceforge to the correct repo's 5. make website available on parchive.github.io (now it has nothing ;)) 6. make sure the documents linked to from the website are on github 7. redirect most stuff from sourceforge to github users: - confirm who is who to add to the parchive organization on github - determine who will take the lead for specific repo's/things to be done unclear: - forums, github does not do forums - mailing lists, could just stay on sourceforge or migrate to something else -- Ike |
From: Ace O. <aol...@gm...> - 2015-05-17 03:37:51
|
It might be worth noting that the Par2TBB site is back online and there is a new drop from May 5th (20150505) which fixes a bug in the Windows Version; from the release notes: - in the Windows version, it was not possible to repair files which were larger than 2GB in size because of a 32-bit signed integer extension bug when handling file offsets. Fixed by always treating file offsets as a 64-bit unsigned integer in both the 32-bit and 64-bit versions of the program. This problem only affected the Windows version so there are no new binary builds of the Mac or Linux versions. It was unclear if any of that code was being used by anyone? I don't see the Author on this chain I'll forward him this message. On Fri, May 15, 2015 at 3:49 AM, Ike Devolder <ike...@gm...> wrote: > simple steps: > > 1. create parchive organization on github (done) > 2. move the repo's over to that organization (par2cmdline is there already) > 3. use cleaned up history for relevant repos and rename original imports > to ...-archived, or ...-imported > 4. move tickets from sourceforge to the correct repo's > 5. make website available on parchive.github.io (now it has nothing ;)) > 6. make sure the documents linked to from the website are on github > 7. redirect most stuff from sourceforge to github > > users: > - confirm who is who to add to the parchive organization on github > - determine who will take the lead for specific repo's/things to be done > > unclear: > - forums, github does not do forums > - mailing lists, could just stay on sourceforge or migrate to something > else > > I'm currently having issues to get online so it might take a while for me > to get my home configuration back in its normal shape. > > 2015-05-13 15:53 GMT+02:00 Michael Nahas <mik...@gm...>: > >> Ike, >> >> It looks like there's a CVS project called "www". I'm guessing that >> holds the website. >> >> CVS instructions: >> http://sourceforge.net/p/parchive/code/?source=navbar >> >> CVS web viewer: >> http://parchive.cvs.sourceforge.net/viewvc/parchive/ >> >> If you can't access it, I can try to build a tarball for you this evening. >> >> >> Ike, do we have a step-by-step plan for moving everything? I know I'm >> still on the hook for the mailinglist. I'll check that out this evening. >> >> Mike >> >> >> >> On Wed, May 13, 2015 at 12:45 AM, Ike Devolder <ike...@gm...> >> wrote: >> >>> On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote: >>> > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote: >>> > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote: >>> > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote: >>> > > > > >>> > > > > I'll prob. do my cleanup anyway, and put it up on a github repo. >>> > > > > I might tell github it's a "fork" of your repo, so people can >>> find it, >>> > > > > even though they would share no commits. (Different parent but >>> same >>> > > > > tree for later commits, once line endings stabilized.) >>> > > > >>> > > > Ok, I have a sanitized-history version of the par2cmdline repo. >>> > > > >>> > > > It's probably going to be a pain to move commits between sanitized >>> > > > and full-history trees, except with git format-patch and stuff like >>> > > > that. So IDK if it makes sense for new development to happen >>> against >>> > > > that tree, or if we should just keep it around for reference. I'll >>> > > > see what happens with a pull request on github. >>> > >>> > What happens is: >>> > >>> > There isn't anything to compare. >>> > >>> > Parchive:master and pcordes:master are >>> > entirely different commit histories. >>> > >>> > >>> > The last 2 commits on pcordes:master are an update to .gitignore, and >>> > a .gitattributes that should avoid anyone creating commits with >>> > non-Unix line endings in the future. >>> > >>> > Attached git format-patch output for them, so you can cherry-pick >>> > them into Parchive:master. >>> > >>> > >>> > > Thanks for this magnificent work. >>> > > >>> > > -- >>> > > Ike >>> > >>> > Thanks, hopefully it's of some use. >>> > >>> > Any thoughts on moving mainline development onto this tree, and >>> > keeping around the messy-line-endings and permissions history as the >>> > historical archive? Instead of the other way around. >>> > >>> > If the official repo can't push/pull from mine, it's not very useful, >>> > and I should probably rebase tbb onto a non-rewritten version of your >>> > tree. Then people could potentially pull branches into their dev >>> > trees to compare against code from other forks. >>> > >>> > -- >>> > #define X(x,y) x##y >>> > Peter Cordes ; e-mail: X(peter@cor , des.ca) >>> > >>> > "The gods confound the man who first found out how to distinguish the >>> hours! >>> > Confound him, too, who in this place set up a sundial, to cut and hack >>> > my day so wretchedly into small pieces!" -- Plautus, 200 BC >>> >>> > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001 >>> > From: Peter Cordes <pe...@co...> >>> > Date: Thu, 7 May 2015 02:08:48 -0300 >>> > Subject: [PATCH 1/2] gitignore: Add more scratch files >>> > >>> > Ignore files generated from: >>> > * performance tuning >>> > * Eclipse >>> > * Mac ._ stuff >>> > * VC++ .suo apparently are local-options and shouldn't be committed >>> > >>> > I sometimes run par2 c test.par2 ... while testing stuff, so ignore >>> test.* >>> > Tweak this if you want to commit a test.h or something. >>> > --- >>> > .gitignore | 16 ++++++++++++++++ >>> > 1 file changed, 16 insertions(+) >>> > >>> > diff --git a/.gitignore b/.gitignore >>> > index 0e5bcaf..bc2e01f 100644 >>> > --- a/.gitignore >>> > +++ b/.gitignore >>> > @@ -10,6 +10,7 @@ par2 >>> > # test output >>> > *.trs >>> > *.log >>> > +testdir/ >>> > >>> > # autotools output >>> > aclocal.m4 >>> > @@ -23,3 +24,18 @@ config.status >>> > configure >>> > stamp-h >>> > stamp-h1 >>> > + >>> > +test.* >>> > +# Linux perf record output >>> > +perf.* >>> > +# gcc -fprofile-use >>> > +*.gcda >>> > + >>> > +# eclipse stuff you get when you point it at a Makefile project >>> > +.cproject >>> > +.project >>> > +.settings >>> > + >>> > +# par2tbb tarballs have MacOS properties floating around, and VC++ >>> .suo >>> > +._* >>> > +*.suo >>> > -- >>> > 2.3.7 >>> > >>> >>> > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001 >>> > From: Peter Cordes <pe...@co...> >>> > Date: Thu, 7 May 2015 02:14:10 -0300 >>> > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits >>> use Unix >>> > line endings. >>> > >>> > --- >>> > .gitattributes | 30 ++++++++++++++++++++++++++++++ >>> > 1 file changed, 30 insertions(+) >>> > create mode 100644 .gitattributes >>> > >>> > diff --git a/.gitattributes b/.gitattributes >>> > new file mode 100644 >>> > index 0000000..08d58f0 >>> > --- /dev/null >>> > +++ b/.gitattributes >>> > @@ -0,0 +1,30 @@ >>> > +# Auto detect text files and perform LF normalization >>> > +# see >>> http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git >>> > + >>> > +* text=auto >>> > + >>> > +*.cpp text >>> > +*.h text >>> > +*.txt text >>> > +*.s text >>> > + >>> > +*.csproj text merge=union >>> > +*.sln text=unset merge=union >>> > +*.vcproj text=unset merge=union >>> > +*.vcxproj* text=unset merge=union >>> > + >>> > +# The VC++ files were already in the repo with DOS line endings >>> > +# This setting would make git store them internally with LF >>> > +#*.sln text merge=union eol=crlf >>> > + >>> > +# instead, use text=unset to tell git to not do any conversions on >>> > +# those files >>> > + >>> > + >>> > +# This will only work well in a repo where all the files have Unix >>> line >>> > +# endings. Having this file in a repo with DOS text files in the >>> tree will >>> > +# make git see those files as changed (to Unix line endings, >>> regardless of >>> > +# what they are in your working copy). >>> > + >>> > +# Conversely, this will make all new commits of text files commit >>> with Unix >>> > +# line endings, regardless of what they are in your working copy. >>> > -- >>> > 2.3.7 >>> > >>> >>> When I have sufficient time, I'll check all your work and start moving >>> everything that is available on sourceforge in its original format to >>> github. >>> >>> I'll probably suffix the original repo's with -archive to indicate those >>> are just imported repos from sourceforge. >>> >>> The cleaned up repo's might become the new upstream after I verified >>> everything. >>> >>> thx >>> >>> >>> -- >>> Ike >>> >> >> > > > -- > Ike > |
From: Ike D. <ike...@gm...> - 2015-05-15 09:49:07
|
simple steps: 1. create parchive organization on github (done) 2. move the repo's over to that organization (par2cmdline is there already) 3. use cleaned up history for relevant repos and rename original imports to ...-archived, or ...-imported 4. move tickets from sourceforge to the correct repo's 5. make website available on parchive.github.io (now it has nothing ;)) 6. make sure the documents linked to from the website are on github 7. redirect most stuff from sourceforge to github users: - confirm who is who to add to the parchive organization on github - determine who will take the lead for specific repo's/things to be done unclear: - forums, github does not do forums - mailing lists, could just stay on sourceforge or migrate to something else I'm currently having issues to get online so it might take a while for me to get my home configuration back in its normal shape. 2015-05-13 15:53 GMT+02:00 Michael Nahas <mik...@gm...>: > Ike, > > It looks like there's a CVS project called "www". I'm guessing that holds > the website. > > CVS instructions: > http://sourceforge.net/p/parchive/code/?source=navbar > > CVS web viewer: > http://parchive.cvs.sourceforge.net/viewvc/parchive/ > > If you can't access it, I can try to build a tarball for you this evening. > > > Ike, do we have a step-by-step plan for moving everything? I know I'm > still on the hook for the mailinglist. I'll check that out this evening. > > Mike > > > > On Wed, May 13, 2015 at 12:45 AM, Ike Devolder <ike...@gm...> > wrote: > >> On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote: >> > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote: >> > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote: >> > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote: >> > > > > >> > > > > I'll prob. do my cleanup anyway, and put it up on a github repo. >> > > > > I might tell github it's a "fork" of your repo, so people can >> find it, >> > > > > even though they would share no commits. (Different parent but >> same >> > > > > tree for later commits, once line endings stabilized.) >> > > > >> > > > Ok, I have a sanitized-history version of the par2cmdline repo. >> > > > >> > > > It's probably going to be a pain to move commits between sanitized >> > > > and full-history trees, except with git format-patch and stuff like >> > > > that. So IDK if it makes sense for new development to happen >> against >> > > > that tree, or if we should just keep it around for reference. I'll >> > > > see what happens with a pull request on github. >> > >> > What happens is: >> > >> > There isn't anything to compare. >> > >> > Parchive:master and pcordes:master are >> > entirely different commit histories. >> > >> > >> > The last 2 commits on pcordes:master are an update to .gitignore, and >> > a .gitattributes that should avoid anyone creating commits with >> > non-Unix line endings in the future. >> > >> > Attached git format-patch output for them, so you can cherry-pick >> > them into Parchive:master. >> > >> > >> > > Thanks for this magnificent work. >> > > >> > > -- >> > > Ike >> > >> > Thanks, hopefully it's of some use. >> > >> > Any thoughts on moving mainline development onto this tree, and >> > keeping around the messy-line-endings and permissions history as the >> > historical archive? Instead of the other way around. >> > >> > If the official repo can't push/pull from mine, it's not very useful, >> > and I should probably rebase tbb onto a non-rewritten version of your >> > tree. Then people could potentially pull branches into their dev >> > trees to compare against code from other forks. >> > >> > -- >> > #define X(x,y) x##y >> > Peter Cordes ; e-mail: X(peter@cor , des.ca) >> > >> > "The gods confound the man who first found out how to distinguish the >> hours! >> > Confound him, too, who in this place set up a sundial, to cut and hack >> > my day so wretchedly into small pieces!" -- Plautus, 200 BC >> >> > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001 >> > From: Peter Cordes <pe...@co...> >> > Date: Thu, 7 May 2015 02:08:48 -0300 >> > Subject: [PATCH 1/2] gitignore: Add more scratch files >> > >> > Ignore files generated from: >> > * performance tuning >> > * Eclipse >> > * Mac ._ stuff >> > * VC++ .suo apparently are local-options and shouldn't be committed >> > >> > I sometimes run par2 c test.par2 ... while testing stuff, so ignore >> test.* >> > Tweak this if you want to commit a test.h or something. >> > --- >> > .gitignore | 16 ++++++++++++++++ >> > 1 file changed, 16 insertions(+) >> > >> > diff --git a/.gitignore b/.gitignore >> > index 0e5bcaf..bc2e01f 100644 >> > --- a/.gitignore >> > +++ b/.gitignore >> > @@ -10,6 +10,7 @@ par2 >> > # test output >> > *.trs >> > *.log >> > +testdir/ >> > >> > # autotools output >> > aclocal.m4 >> > @@ -23,3 +24,18 @@ config.status >> > configure >> > stamp-h >> > stamp-h1 >> > + >> > +test.* >> > +# Linux perf record output >> > +perf.* >> > +# gcc -fprofile-use >> > +*.gcda >> > + >> > +# eclipse stuff you get when you point it at a Makefile project >> > +.cproject >> > +.project >> > +.settings >> > + >> > +# par2tbb tarballs have MacOS properties floating around, and VC++ .suo >> > +._* >> > +*.suo >> > -- >> > 2.3.7 >> > >> >> > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001 >> > From: Peter Cordes <pe...@co...> >> > Date: Thu, 7 May 2015 02:14:10 -0300 >> > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits use >> Unix >> > line endings. >> > >> > --- >> > .gitattributes | 30 ++++++++++++++++++++++++++++++ >> > 1 file changed, 30 insertions(+) >> > create mode 100644 .gitattributes >> > >> > diff --git a/.gitattributes b/.gitattributes >> > new file mode 100644 >> > index 0000000..08d58f0 >> > --- /dev/null >> > +++ b/.gitattributes >> > @@ -0,0 +1,30 @@ >> > +# Auto detect text files and perform LF normalization >> > +# see >> http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git >> > + >> > +* text=auto >> > + >> > +*.cpp text >> > +*.h text >> > +*.txt text >> > +*.s text >> > + >> > +*.csproj text merge=union >> > +*.sln text=unset merge=union >> > +*.vcproj text=unset merge=union >> > +*.vcxproj* text=unset merge=union >> > + >> > +# The VC++ files were already in the repo with DOS line endings >> > +# This setting would make git store them internally with LF >> > +#*.sln text merge=union eol=crlf >> > + >> > +# instead, use text=unset to tell git to not do any conversions on >> > +# those files >> > + >> > + >> > +# This will only work well in a repo where all the files have Unix line >> > +# endings. Having this file in a repo with DOS text files in the tree >> will >> > +# make git see those files as changed (to Unix line endings, >> regardless of >> > +# what they are in your working copy). >> > + >> > +# Conversely, this will make all new commits of text files commit with >> Unix >> > +# line endings, regardless of what they are in your working copy. >> > -- >> > 2.3.7 >> > >> >> When I have sufficient time, I'll check all your work and start moving >> everything that is available on sourceforge in its original format to >> github. >> >> I'll probably suffix the original repo's with -archive to indicate those >> are just imported repos from sourceforge. >> >> The cleaned up repo's might become the new upstream after I verified >> everything. >> >> thx >> >> >> -- >> Ike >> > > -- Ike |
From: Ike D. <ike...@gm...> - 2015-05-15 09:33:31
|
I'm going to have some delay om some stuff, my router died so I'm not as connected as I should be. 2015-05-13 21:13 GMT+02:00 Ryan Gallagher <cli...@gm...>: > > On Wed, May 13, 2015 at 8:53 AM, Michael Nahas <mik...@gm...> > wrote: > >> It looks like there's a CVS project called "www". I'm guessing that >> holds the website. > > > We almost checked the website into cvs at one point. nothing there. > tarball is the way to go, someone who has shell access can zip it up, > otherwise I can fetch it for you, just let me know. > > Ryan > binerman / clickykbd > -- Ike |
From: Ryan G. <cli...@gm...> - 2015-05-13 19:13:43
|
On Wed, May 13, 2015 at 8:53 AM, Michael Nahas <mik...@gm...> wrote: > It looks like there's a CVS project called "www". I'm guessing that holds > the website. We almost checked the website into cvs at one point. nothing there. tarball is the way to go, someone who has shell access can zip it up, otherwise I can fetch it for you, just let me know. Ryan binerman / clickykbd |
From: Michael N. <mik...@gm...> - 2015-05-13 13:54:06
|
Ike, It looks like there's a CVS project called "www". I'm guessing that holds the website. CVS instructions: http://sourceforge.net/p/parchive/code/?source=navbar CVS web viewer: http://parchive.cvs.sourceforge.net/viewvc/parchive/ If you can't access it, I can try to build a tarball for you this evening. Ike, do we have a step-by-step plan for moving everything? I know I'm still on the hook for the mailinglist. I'll check that out this evening. Mike On Wed, May 13, 2015 at 12:45 AM, Ike Devolder <ike...@gm...> wrote: > On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote: > > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote: > > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote: > > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote: > > > > > > > > > > I'll prob. do my cleanup anyway, and put it up on a github repo. > > > > > I might tell github it's a "fork" of your repo, so people can find > it, > > > > > even though they would share no commits. (Different parent but > same > > > > > tree for later commits, once line endings stabilized.) > > > > > > > > Ok, I have a sanitized-history version of the par2cmdline repo. > > > > > > > > It's probably going to be a pain to move commits between sanitized > > > > and full-history trees, except with git format-patch and stuff like > > > > that. So IDK if it makes sense for new development to happen against > > > > that tree, or if we should just keep it around for reference. I'll > > > > see what happens with a pull request on github. > > > > What happens is: > > > > There isn't anything to compare. > > > > Parchive:master and pcordes:master are > > entirely different commit histories. > > > > > > The last 2 commits on pcordes:master are an update to .gitignore, and > > a .gitattributes that should avoid anyone creating commits with > > non-Unix line endings in the future. > > > > Attached git format-patch output for them, so you can cherry-pick > > them into Parchive:master. > > > > > > > Thanks for this magnificent work. > > > > > > -- > > > Ike > > > > Thanks, hopefully it's of some use. > > > > Any thoughts on moving mainline development onto this tree, and > > keeping around the messy-line-endings and permissions history as the > > historical archive? Instead of the other way around. > > > > If the official repo can't push/pull from mine, it's not very useful, > > and I should probably rebase tbb onto a non-rewritten version of your > > tree. Then people could potentially pull branches into their dev > > trees to compare against code from other forks. > > > > -- > > #define X(x,y) x##y > > Peter Cordes ; e-mail: X(peter@cor , des.ca) > > > > "The gods confound the man who first found out how to distinguish the > hours! > > Confound him, too, who in this place set up a sundial, to cut and hack > > my day so wretchedly into small pieces!" -- Plautus, 200 BC > > > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001 > > From: Peter Cordes <pe...@co...> > > Date: Thu, 7 May 2015 02:08:48 -0300 > > Subject: [PATCH 1/2] gitignore: Add more scratch files > > > > Ignore files generated from: > > * performance tuning > > * Eclipse > > * Mac ._ stuff > > * VC++ .suo apparently are local-options and shouldn't be committed > > > > I sometimes run par2 c test.par2 ... while testing stuff, so ignore > test.* > > Tweak this if you want to commit a test.h or something. > > --- > > .gitignore | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/.gitignore b/.gitignore > > index 0e5bcaf..bc2e01f 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -10,6 +10,7 @@ par2 > > # test output > > *.trs > > *.log > > +testdir/ > > > > # autotools output > > aclocal.m4 > > @@ -23,3 +24,18 @@ config.status > > configure > > stamp-h > > stamp-h1 > > + > > +test.* > > +# Linux perf record output > > +perf.* > > +# gcc -fprofile-use > > +*.gcda > > + > > +# eclipse stuff you get when you point it at a Makefile project > > +.cproject > > +.project > > +.settings > > + > > +# par2tbb tarballs have MacOS properties floating around, and VC++ .suo > > +._* > > +*.suo > > -- > > 2.3.7 > > > > > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001 > > From: Peter Cordes <pe...@co...> > > Date: Thu, 7 May 2015 02:14:10 -0300 > > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits use > Unix > > line endings. > > > > --- > > .gitattributes | 30 ++++++++++++++++++++++++++++++ > > 1 file changed, 30 insertions(+) > > create mode 100644 .gitattributes > > > > diff --git a/.gitattributes b/.gitattributes > > new file mode 100644 > > index 0000000..08d58f0 > > --- /dev/null > > +++ b/.gitattributes > > @@ -0,0 +1,30 @@ > > +# Auto detect text files and perform LF normalization > > +# see > http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git > > + > > +* text=auto > > + > > +*.cpp text > > +*.h text > > +*.txt text > > +*.s text > > + > > +*.csproj text merge=union > > +*.sln text=unset merge=union > > +*.vcproj text=unset merge=union > > +*.vcxproj* text=unset merge=union > > + > > +# The VC++ files were already in the repo with DOS line endings > > +# This setting would make git store them internally with LF > > +#*.sln text merge=union eol=crlf > > + > > +# instead, use text=unset to tell git to not do any conversions on > > +# those files > > + > > + > > +# This will only work well in a repo where all the files have Unix line > > +# endings. Having this file in a repo with DOS text files in the tree > will > > +# make git see those files as changed (to Unix line endings, regardless > of > > +# what they are in your working copy). > > + > > +# Conversely, this will make all new commits of text files commit with > Unix > > +# line endings, regardless of what they are in your working copy. > > -- > > 2.3.7 > > > > When I have sufficient time, I'll check all your work and start moving > everything that is available on sourceforge in its original format to > github. > > I'll probably suffix the original repo's with -archive to indicate those > are just imported repos from sourceforge. > > The cleaned up repo's might become the new upstream after I verified > everything. > > thx > > > -- > Ike > |
From: Ike D. <ike...@gm...> - 2015-05-13 05:46:08
|
On Thu, May 07, 2015 at 02:29:33AM -0300, Peter Cordes wrote: > On Thu, May 07, 2015 at 06:39:12AM +0200, Ike Devolder wrote: > > On Thu, May 07, 2015 at 01:08:04AM -0300, Peter Cordes wrote: > > > On Wed, May 06, 2015 at 03:12:38AM -0300, Peter Cordes wrote: > > > > > > > > I'll prob. do my cleanup anyway, and put it up on a github repo. > > > > I might tell github it's a "fork" of your repo, so people can find it, > > > > even though they would share no commits. (Different parent but same > > > > tree for later commits, once line endings stabilized.) > > > > > > Ok, I have a sanitized-history version of the par2cmdline repo. > > > > > > It's probably going to be a pain to move commits between sanitized > > > and full-history trees, except with git format-patch and stuff like > > > that. So IDK if it makes sense for new development to happen against > > > that tree, or if we should just keep it around for reference. I'll > > > see what happens with a pull request on github. > > What happens is: > > There isn't anything to compare. > > Parchive:master and pcordes:master are > entirely different commit histories. > > > The last 2 commits on pcordes:master are an update to .gitignore, and > a .gitattributes that should avoid anyone creating commits with > non-Unix line endings in the future. > > Attached git format-patch output for them, so you can cherry-pick > them into Parchive:master. > > > > Thanks for this magnificent work. > > > > -- > > Ike > > Thanks, hopefully it's of some use. > > Any thoughts on moving mainline development onto this tree, and > keeping around the messy-line-endings and permissions history as the > historical archive? Instead of the other way around. > > If the official repo can't push/pull from mine, it's not very useful, > and I should probably rebase tbb onto a non-rewritten version of your > tree. Then people could potentially pull branches into their dev > trees to compare against code from other forks. > > -- > #define X(x,y) x##y > Peter Cordes ; e-mail: X(peter@cor , des.ca) > > "The gods confound the man who first found out how to distinguish the hours! > Confound him, too, who in this place set up a sundial, to cut and hack > my day so wretchedly into small pieces!" -- Plautus, 200 BC > From df75089e6f7513b6967550c4fd010b5f9af72c9c Mon Sep 17 00:00:00 2001 > From: Peter Cordes <pe...@co...> > Date: Thu, 7 May 2015 02:08:48 -0300 > Subject: [PATCH 1/2] gitignore: Add more scratch files > > Ignore files generated from: > * performance tuning > * Eclipse > * Mac ._ stuff > * VC++ .suo apparently are local-options and shouldn't be committed > > I sometimes run par2 c test.par2 ... while testing stuff, so ignore test.* > Tweak this if you want to commit a test.h or something. > --- > .gitignore | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 0e5bcaf..bc2e01f 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -10,6 +10,7 @@ par2 > # test output > *.trs > *.log > +testdir/ > > # autotools output > aclocal.m4 > @@ -23,3 +24,18 @@ config.status > configure > stamp-h > stamp-h1 > + > +test.* > +# Linux perf record output > +perf.* > +# gcc -fprofile-use > +*.gcda > + > +# eclipse stuff you get when you point it at a Makefile project > +.cproject > +.project > +.settings > + > +# par2tbb tarballs have MacOS properties floating around, and VC++ .suo > +._* > +*.suo > -- > 2.3.7 > > From bb3e93fe9dac4f992215263391a3a64246b66893 Mon Sep 17 00:00:00 2001 > From: Peter Cordes <pe...@co...> > Date: Thu, 7 May 2015 02:14:10 -0300 > Subject: [PATCH 2/2] .gitattributes: make everyone's future commits use Unix > line endings. > > --- > .gitattributes | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > create mode 100644 .gitattributes > > diff --git a/.gitattributes b/.gitattributes > new file mode 100644 > index 0000000..08d58f0 > --- /dev/null > +++ b/.gitattributes > @@ -0,0 +1,30 @@ > +# Auto detect text files and perform LF normalization > +# see http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git > + > +* text=auto > + > +*.cpp text > +*.h text > +*.txt text > +*.s text > + > +*.csproj text merge=union > +*.sln text=unset merge=union > +*.vcproj text=unset merge=union > +*.vcxproj* text=unset merge=union > + > +# The VC++ files were already in the repo with DOS line endings > +# This setting would make git store them internally with LF > +#*.sln text merge=union eol=crlf > + > +# instead, use text=unset to tell git to not do any conversions on > +# those files > + > + > +# This will only work well in a repo where all the files have Unix line > +# endings. Having this file in a repo with DOS text files in the tree will > +# make git see those files as changed (to Unix line endings, regardless of > +# what they are in your working copy). > + > +# Conversely, this will make all new commits of text files commit with Unix > +# line endings, regardless of what they are in your working copy. > -- > 2.3.7 > When I have sufficient time, I'll check all your work and start moving everything that is available on sourceforge in its original format to github. I'll probably suffix the original repo's with -archive to indicate those are just imported repos from sourceforge. The cleaned up repo's might become the new upstream after I verified everything. thx -- Ike |
From: Ike D. <ike...@gm...> - 2015-05-13 05:41:47
|
On Thu, Apr 30, 2015 at 01:46:28PM -0500, Ryan Gallagher wrote: > On Thu, Apr 30, 2015 at 10:04 AM, Michael Nahas <mik...@gm...> > wrote: > > > Right now, I'll try to contact the people who have administrator > > privileges on SourceForge. We will need them for the mailing list archives > > and to eventually shutter the project there. > > > Hi Mike. > > I'm still around, and happy to grant you admin privs if it will let me, if > you have trouble raising any of the other admins that is. > My original involvement was just the website, and what a relic it is now > (though glad you still love the banner), I didn't deserve admin privs but > back then you had to have them to get shell access on sourceforge i think. > (which is probably still how you need to access the public web files). > > Can't commit much time to help you, but happy to flip bits or grab things > that only an admin can do if necessary. > > Ryan Gallagher > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Parchive-devel mailing list > Par...@li... > https://lists.sourceforge.net/lists/listinfo/parchive-devel Hi Ryan, Could you send me the website code ? What is currently up on parchive.sourceforge.net ? I could just import the old website on github and start from there to update it a little bit. Once the old website is imported on github, maybe the parchive.sourceforge.net could redirect to parchive.github.io. thx -- Ike |