The bounce mail talked about a message being rejected as it was over the 30MB limit; I saw that the attachments were pretty small but I wasn't sure if one if the attachments had been stripped or not. Better safe than sorry! "Curry, Matthew Leon" <[email protected]> wrote: Yeah, we had that issue before, too. I think I've gotten HTML mails that were bigger than Shane's attachments, though. :) Matthew On Feb 20, 2012, at 9:13 AM, Dries Kimpe wrote:

Just a note: I got some messages from the mailing list software that the clemson server was refusing emails because of large attachments.

It's probably best not to send large attachments to the mailing list...

Dries

* Matthew Farmer <[email protected]> [2012-02-20 10:06:06]:

...

All,

...

I am running a very high fever and am basically out of commission. This has somewhat hampered my development efforts.

...

I am almost done with getting libssm+ssmtests+transports cleaned up, tested, and tagged, but in my present state I just can't do it, and frankly I need to be horizontal and unconscious. So in the interest of productivity, I'm attaching the 90% version of libssm itself and the libssmp_localmem transport. (TCP and MPI are pending. InfiniBand is * really* pending.) The API is now stable and the general order of operations is settled. After testing and documentation this will become the 0.6 tag release.

...

This code release (and the drop it's leading up to) includes all discussed features to date: - "normal" iovec memory semantics (no more custom iovecs or "chains" -- multiple buffers can be added directly to match entries) - much stricter memory management (no layer violations) and the associated scaffolding - get/put offests (both read and write) - local-side-only scatter-gathers (SSM_ME_VECTOR, implies that when initiating a get or a put all buffers instead of the first should be used for initiator only) - the buffer matching Lee discussed (i.e. size only matched against the first buffer, and special event results SSM_RESULT_NO_BUFFERS) - the never-unlink behavior (currently the default -- more on this later) - everything needed for ssm_cancel to function (although it doesn't technically function yet) - better naming and more sensible namespaces - fairly extensive refactoring that cut down on LOC and removed a lot of indirection (no more formal modules, just some custom SSM data types) - support for non-concurrent (i.e. non-threaded) SSM that only makes progress on ssm_wait (this is actually the *only* option right now, but the core is written to make adding some other options e.g. pthreads trivial).

...

For interested parties, the public interface is in common/ssm.h, which in turn includes the stuff from common/ssm/main. Those files in main are the top-level API functions that you use with SSM. Comments and documentation are sparse right now, but this is just meant to give everyone a look while I get it finalized and tested (despite which I'm sure Matthew Curry will immediately find a bug). Other files in common/ssm are either internal or legacy; the relevant ones are included from ssm.h and everything else is doomed.

...

This is a versioned export, not a tag, and can be reproduced like so: svn export -r 931 https://svn.cis.uab.edu/hpcl/Nebula/SSM/libssm_ref/branches/libssm_ref-buffe... svn export -r 931 https://svn.cis.uab.edu/hpcl/Nebula/SSM/libssmp_localmem/branches/libssmp_li...

...

PLEASE NOTE THAT THIS IS NOT A FORMAL TAG/DROP AND IS UNTESTED, BUGGY CODE. PLEASE DON'T RELY ON THIS WORKING 100%, BUT PLAN ON A STABLE VERSION VERY SOON. The API is stable, so building against is futureproof, but there has been literally one test case ran on the code. This is just meant to show you the interface, and to peek at the implementation if something isn't clear. Everything should build -- please tell me if it doesn't -- but it would be brash to link and start calling functions.

...

When I do the 0.6 drop I'll write a brief changelog and a general usage guide.

...

I will try to be awake for the call -- if I'm not there, let this function as my status report. I would greatly appreciate if any discourse regarding this code release was via e-mail, as it causes me no small discomfort to speak, whereas typing just requires persistence. Moving forward, I would estimate only a handful of hours to the 0.6 drop I keep promising, but that is contingent upon my health and ability to write code without earning the bitter distrust of gcc. (warning: user is writing gibberish)

...

Anyway, take a look, and any questions or comments please let me know. Guys at ANL, I expect this to be a very close approximation of a final interface, so please give me any comments. I apologize for the delay in tested+stable product.

...

If any of this e-mail sounds rambling or doesn't make sense I apologize *grin*

...

I'm going back to sleep. Godspeed, all.

...

Shane

...

_____________________________________________

...

ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg

_____________________________________________

ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg

_____________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg