[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 09 May 2011 21:02:50 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: FW: the jumbo-2 RC1
On 2011-05-09 17:48, jfoug wrote:
> For jumbo-3, here is what I think we were wanting to target:
>
> 1.Utf-8 -> Unicode (would we also benefit from a simple but faster ASCII
> -> Unicode, at some areas?)
I'm not sure what you mean here. The faster ISO-8859-1-to-Unicode
conversion is what we have had all the time without the UTF-8 patch.
Nothing can be faster than that. With UTF-8 patch, we still have that as
default when not giving the --utf8 flag. I think you know all that so I
probably misunderstand what you wrote.
As for doc/ there is a UTF8 user documentation and UTF8-DEVEL.txt (maybe
we should drop the .txt) for coders wanting to use the shared UTF-8
functions.
And MPI has README.mpi (file named like that for years) for users, also
including some compiling hints (and MPI environment). Now come to think
of it, maybe I forgot to add the simple fact you actually need to
un-comment the MPIFLAGS line in Makefile...
> 3.Possible build changes for formats listing (options.c), for formats
> declaration code (john.c), and formats init code (john.c), possibly done
> at the makefile level. Also, it might be possible to have the .o
> inclusion IN the makefile be auto computed also.
Maybe we need to agree on (or, much easier, have Solar dictate) a more
unified way of using the format tags (FORMAT_LABEL, FORMAT_NAME,
ALGORITHM_NAME, BENCHMARK_COMMENT) so they are, for example, showing
MMX/SSE/whatever in the same way (inside the brackets when testing?
That's ALGORITHM_NAME).
> Am I missing anything, or have too many things been ‘packed’ into this
> jumbo? As for releasing, I think the method Solar mentioned of having
> multiple jumbos released, trying to generic-ify many of the more
> used/wanted patches into jumbos, and releasing them to the john-dev
> group, and once we have most of the active stuff stabilized and in
> jumbo, then release it to the world. Thus, some of these ‘projects’ may
> be better to get into jumbo-4, jumbo-5, etc, etc.
I think the fastest way to get stuff stable again is to make an utter
mess at once and then sort it out. That's just my opinion, and the
rationale is that all major core changes will be made and everybodys
patches will be a lot smaller and clash a lot less from that point.
So we/you/Solar/I could create a Jumbo-3 (still not for the masses)
right now with MPI, UTF-8 and the auto-formats-list added (btw the
posted version works fine with your Jumbo-2 except it starts with
listing md5-gen 21 times or so :). Then as soon as Intrinsics are ready,
throw them in for a Jumbo-4. If not, release a Jumbo-4 as soon as it's
there. Likewise, as soon as someone updates the SybaseASE/rar/ssh
formats (easy fixes) we can throw out a new Jumbo-RC with them, bumping
the revision number. Same goes for the Makefile ideas, if someone has
the time to look at that. During this time bugs will be found and fixed
but those patches will likely be small, non-intrusive and not by far as
demanding on exact versions of everything around.
I believe it wouldn't take very long before things are pretty stable
again, and from that day, format patches will almost never clash (if we
get that Makefile magic)!
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
