From owner-freebsd-haskell@freebsd.org Mon Oct 15 08:06:42 2018 Return-Path: Delivered-To: freebsd-haskell@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF4B510D2E08 for ; Mon, 15 Oct 2018 08:06:42 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 866DE898B8 for ; Mon, 15 Oct 2018 08:06:42 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: by straasha.imrryr.org (Postfix, from userid 1001) id DF30016464; Mon, 15 Oct 2018 04:06:40 -0400 (EDT) Date: Mon, 15 Oct 2018 04:06:40 -0400 From: Viktor Dukhovni To: freebsd-haskell@freebsd.org Subject: Updating ports to GHC 8.4.4? Message-ID: <20181015080640.GA983@straasha.imrryr.org> Reply-To: freebsd-haskell@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-haskell@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: FreeBSD-specific Haskell issues and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 08:06:43 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The Haskell project has just released GHC 8.4.4, which is a bugfix release for 8.4.3 fixing non-trivial bugs: https://mail.haskell.org/pipermail/haskell-cafe/2018-October/130090.html Is anyone planning to update the FreeBSD port? If so, please consider the attached additional patches to the port "files" directory. I contributed the improved OSMem.c upstream, but this has only been merged into GHC 8.6.x, and yet this also win for 8.4, and I've been using it intensively in 8.4.3 (my code runs for 4.5 hours allocating a cumulative 4.6TB of memory). In addition I'm adding a missing LLVM target for amd64. The attached files are patching patches, I hope that's OK. If there's some other form in which to make these available, please let me know. -- Viktor. --8t9RHnE3ZwKMSgU+ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Backport-memory-allocation-improvements-from-8.6.patch" >From 1490ba37a2d5862a3b33c168394e45a7f7a0687a Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Mon, 15 Oct 2018 03:54:12 -0400 Subject: [PATCH 1/3] Backport memory allocation improvements from 8.6 1. Enable two-step allocator on FreeBSD Simplify #ifdef nesting and use MAP_GUARD on FreeBSD and similar systems. This allows the two-step allocator to be used on FreeBSD, fixing #15348. 2. rts: Query system rlimit for maximum address-space size When we attempt to reserve the heap, we query the system's rlimit to establish the starting point for our search over sizes. 3. rts/posix: Use less aggressive backoff schedule for heap reservation sizing When we allocate the heap on POSIX platforms we generally just ask for a 1TB chunk of address space and call it a day. However, if the user has set a ulimit then this request will fail. In this case we would previously try successively smaller allocation requests, reducing the request size by a factor of two each time. However, this means that GHC will significantly allocate a significantly smaller heap than the available physical memory size in some circumstances. Imagine, for instance, a machine with 512 GB of physical memory but a ulimit of 511 GB: we would be limited to a 256 GB heap. We now use a less aggressive back-off policy, reducing by one-eighth the last allocation size each try. --- patch-rts__posix__OSMem.c | 251 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 251 insertions(+) create mode 100644 patch-rts__posix__OSMem.c diff --git a/patch-rts__posix__OSMem.c b/patch-rts__posix__OSMem.c new file mode 100644 index 0000000..e6aacfb --- /dev/null +++ b/patch-rts__posix__OSMem.c @@ -0,0 +1,251 @@ +--- rts/posix/OSMem.c 2017-11-28 11:39:14.000000000 -0500 ++++ rts/posix/OSMem.c +@@ -36,6 +36,10 @@ + #if defined(HAVE_NUMAIF_H) + #include + #endif ++#if defined(HAVE_SYS_RESOURCE_H) && defined(HAVE_SYS_TIME_H) ++#include ++#include ++#endif + + #include + +@@ -45,6 +49,29 @@ + #include + #endif + ++#ifndef MAP_FAILED ++# define MAP_FAILED ((void *)-1) ++#endif ++ ++#if defined(hpux_HOST_OS) ++# ifndef MAP_ANON ++# define MAP_ANON MAP_ANONYMOUS ++# endif ++#endif ++ ++#ifndef darwin_HOST_OS ++# undef RESERVE_FLAGS ++# if defined(MAP_GUARD) ++# define RESERVE_FLAGS MAP_GUARD /* FreeBSD */ ++# elif defined(MAP_NORESERVE) ++# define RESERVE_FLAGS MAP_NORESERVE | MAP_ANON | MAP_PRIVATE; ++# else ++# if defined(USE_LARGE_ADDRESS_SPACE) ++# error USE_LARGE_ADDRESS_SPACE needs MAP_NORESERVE or MAP_GUARD ++# endif ++# endif ++#endif ++ + static void *next_request = 0; + + void osMemInit(void) +@@ -98,8 +125,10 @@ void osMemInit(void) + The naming is chosen from the Win32 API (VirtualAlloc) which does the + same thing and has done so forever, while support for this in Unix systems + has only been added recently and is hidden in the posix portability mess. +- It is confusing because to get the reserve behavior we need MAP_NORESERVE +- (which tells the kernel not to allocate backing space), but heh... ++ The Linux manpage suggests that mmap must be passed MAP_NORESERVE in order ++ to get reservation-only behavior. It is confusing because to get the reserve ++ behavior we need MAP_NORESERVE (which tells the kernel not to allocate backing ++ space), but heh... + */ + enum + { +@@ -108,6 +137,44 @@ enum + MEM_RESERVE_AND_COMMIT = MEM_RESERVE | MEM_COMMIT + }; + ++#if defined(linux_HOST_OS) ++static void * ++linux_retry_mmap(int operation, W_ size, void *ret, void *addr, int prot, int flags) ++{ ++ if (addr != 0 && (operation & MEM_RESERVE)) { ++ // Try again with no hint address. ++ // It's not clear that this can ever actually help, ++ // but since our alternative is to abort, we may as well try. ++ ret = mmap(0, size, prot, flags, -1, 0); ++ } ++ if (ret == MAP_FAILED && errno == EPERM) { ++ // Linux is not willing to give us any mapping, ++ // so treat this as an out-of-memory condition ++ // (really out of virtual address space). ++ errno = ENOMEM; ++ } ++ return ret; ++} ++#endif /* defined(linux_HOST_OS) */ ++ ++static void ++post_mmap_madvise(int operation, W_ size, void *ret) ++{ ++#if defined(MADV_WILLNEED) ++ if (operation & MEM_COMMIT) { ++ madvise(ret, size, MADV_WILLNEED); ++# if defined(MADV_DODUMP) ++ madvise(ret, size, MADV_DODUMP); ++# endif ++ } else { ++ madvise(ret, size, MADV_DONTNEED); ++# if defined(MADV_DONTDUMP) ++ madvise(ret, size, MADV_DONTDUMP); ++# endif ++ } ++#endif ++} ++ + /* Returns NULL on failure; errno set */ + static void * + my_mmap (void *addr, W_ size, int operation) +@@ -149,69 +216,44 @@ my_mmap (void *addr, W_ size, int operation) + VM_PROT_READ|VM_PROT_WRITE); + } + +-#else ++#else /* defined(darwin_HOST_OS) */ + + int prot, flags; +- if (operation & MEM_COMMIT) ++ if (operation & MEM_COMMIT) { + prot = PROT_READ | PROT_WRITE; +- else ++ } else { + prot = PROT_NONE; +- if (operation == MEM_RESERVE) +-# if defined(MAP_NORESERVE) +- flags = MAP_NORESERVE; ++ } ++ ++ if (operation == MEM_RESERVE) { ++# if defined(RESERVE_FLAGS) ++ flags = RESERVE_FLAGS; + # else +-# if defined(USE_LARGE_ADDRESS_SPACE) +-# error USE_LARGE_ADDRESS_SPACE needs MAP_NORESERVE +-# endif + errorBelch("my_mmap(,,MEM_RESERVE) not supported on this platform"); + # endif +- else if (operation == MEM_COMMIT) +- flags = MAP_FIXED; +- else +- flags = 0; ++ } else if (operation == MEM_COMMIT) { ++ flags = MAP_FIXED | MAP_ANON | MAP_PRIVATE; ++ } else { ++ flags = MAP_ANON | MAP_PRIVATE; ++ } + +-#if defined(hpux_HOST_OS) +- ret = mmap(addr, size, prot, flags | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); +-#elif defined(linux_HOST_OS) +- ret = mmap(addr, size, prot, flags | MAP_ANON | MAP_PRIVATE, -1, 0); +- if (ret == (void *)-1 && errno == EPERM) { ++ ret = mmap(addr, size, prot, flags, -1, 0); ++# if defined(linux_HOST_OS) ++ if (ret == MAP_FAILED && errno == EPERM) { + // Linux may return EPERM if it tried to give us + // a chunk of address space below mmap_min_addr, + // See Trac #7500. +- if (addr != 0 && (operation & MEM_RESERVE)) { +- // Try again with no hint address. +- // It's not clear that this can ever actually help, +- // but since our alternative is to abort, we may as well try. +- ret = mmap(0, size, prot, flags | MAP_ANON | MAP_PRIVATE, -1, 0); +- } +- if (ret == (void *)-1 && errno == EPERM) { +- // Linux is not willing to give us any mapping, +- // so treat this as an out-of-memory condition +- // (really out of virtual address space). +- errno = ENOMEM; +- } ++ ret = linux_retry_mmap(operation, size, ret, addr, prot, flags); + } +- +- if (operation & MEM_COMMIT) { +- madvise(ret, size, MADV_WILLNEED); +-#if defined(MADV_DODUMP) +- madvise(ret, size, MADV_DODUMP); +-#endif +- } else { +- madvise(ret, size, MADV_DONTNEED); +-#if defined(MADV_DONTDUMP) +- madvise(ret, size, MADV_DONTDUMP); +-#endif +- } +- +-#else +- ret = mmap(addr, size, prot, flags | MAP_ANON | MAP_PRIVATE, -1, 0); +-#endif +-#endif +- +- if (ret == (void *)-1) { ++# endif ++ if (ret == MAP_FAILED) { + return NULL; + } ++#endif /* defined(darwin_HOST_OS) */ ++ ++ // Map in committed pages rather than take a fault for each chunk. ++ // Also arrange to include them in core-dump files. ++ post_mmap_madvise(operation, size, ret); + + return ret; + } +@@ -435,6 +477,8 @@ osTryReserveHeapMemory (W_ len, void *hint) + void *base, *top; + void *start, *end; + ++ ASSERT((len & ~MBLOCK_MASK) == len); ++ + /* We try to allocate len + MBLOCK_SIZE, + because we need memory which is MBLOCK_SIZE aligned, + and then we discard what we don't need */ +@@ -500,8 +544,19 @@ void *osReserveHeapMemory(void *startAddressPtr, W_ *len) + (void*)startAddress, (void*)minimumAddress); + } + ++#if defined(HAVE_SYS_RESOURCE_H) && defined(HAVE_SYS_TIME_H) ++ struct rlimit limit; ++ if (!getrlimit(RLIMIT_AS, &limit) ++ && limit.rlim_cur > 0 ++ && *len > limit.rlim_cur) { ++ *len = limit.rlim_cur; ++ } ++#endif ++ + attempt = 0; + while (1) { ++ *len &= ~MBLOCK_MASK; ++ + if (*len < MBLOCK_SIZE) { + // Give up if the system won't even give us 16 blocks worth of heap + barf("osReserveHeapMemory: Failed to allocate heap storage"); +@@ -512,9 +567,14 @@ void *osReserveHeapMemory(void *startAddressPtr, W_ *len) + if (at == NULL) { + // This means that mmap failed which we take to mean that we asked + // for too much memory. This can happen due to POSIX resource +- // limits. In this case we reduce our allocation request by a factor +- // of two and try again. +- *len /= 2; ++ // limits. In this case we reduce our allocation request by a ++ // fraction of the current size and try again. ++ // ++ // Note that the previously would instead decrease the request size ++ // by a factor of two; however, this meant that significant amounts ++ // of memory will be wasted (e.g. imagine a machine with 512GB of ++ // physical memory but a 511GB ulimit). See #14492. ++ *len -= *len / 8; + } else if ((W_)at >= minimumAddress) { + // Success! We were given a block of memory starting above the 8 GB + // mark, which is what we were looking for. +@@ -536,7 +596,7 @@ void osCommitMemory(void *at, W_ size) + { + void *r = my_mmap(at, size, MEM_COMMIT); + if (r == NULL) { +- barf("Unable to commit %d bytes of memory", size); ++ barf("Unable to commit %" FMT_Word " bytes of memory", size); + } + } + -- 2.19.1 --8t9RHnE3ZwKMSgU+ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-use_large_address_space-no-no-longer-needed.patch" >From 89fabf4d28d312ac20dbce910450e02511dba26c Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Mon, 15 Oct 2018 03:37:54 -0400 Subject: [PATCH 2/3] use_large_address_space=no no longer needed --- patch-configure.ac | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/patch-configure.ac b/patch-configure.ac index 4d19057..92938eb 100644 --- a/patch-configure.ac +++ b/patch-configure.ac @@ -10,15 +10,3 @@ # If 'host' and 'target' differ, then this means we are building a cross-compiler. if test "$TargetPlatform" != "$HostPlatform" ; then CrossCompiling=YES -@@ -1163,6 +1158,11 @@ if test "$ac_cv_sizeof_void_p" -eq 8 ; t - # The flag MAP_NORESERVE is supported for source compatibility reasons, - # but is completely ignored by OS mmap - use_large_address_space=no -+ elif test "$ghc_host_os" = "freebsd" ; then -+ # FreeBSD does not support mmap with MAP_NORESERVE, removed in r273250. -+ # The flag MAP_NORESERVE is supported for source compatibility reasons, -+ # but is completely ignored by OS mmap -+ use_large_address_space=no - else - AC_CHECK_DECLS([MAP_NORESERVE, MADV_FREE, MADV_DONTNEED],[],[], - [ -- 2.19.1 --8t9RHnE3ZwKMSgU+ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0003-FreeBSD-amd64-LLVM-target.patch" >From ac6d71b685eb07067b24cd1573a685f7c0a6fbe9 Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Mon, 15 Oct 2018 03:54:40 -0400 Subject: [PATCH 3/3] FreeBSD amd64 LLVM target --- patch-llvm-targets | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/patch-llvm-targets b/patch-llvm-targets index 8ea0574..f6220ae 100644 --- a/patch-llvm-targets +++ b/patch-llvm-targets @@ -1,6 +1,14 @@ --- llvm-targets.orig 2018-03-17 14:04:41 UTC +++ llvm-targets -@@ -20,4 +20,7 @@ +@@ -15,6 +15,7 @@ + ,("x86_64-unknown-linux", ("e-m:e-i64:64-f80:128-n8:16:32:64-S128", "x86-64", "")) + ,("armv7-unknown-linux-androideabi", ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "generic", "")) + ,("aarch64-unknown-linux-android", ("e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128", "generic", "+neon")) ++,("amd64-portbld-freebsd", ("e-m:e-i64:64-f80:128-n8:16:32:64-S128", "x86-64", "")) + ,("arm-unknown-nto-qnx-eabi", ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm7tdmi", "+strict-align")) + ,("i386-apple-darwin", ("e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128", "yonah", "")) + ,("x86_64-apple-darwin", ("e-m:o-i64:64-f80:128-n8:16:32:64-S128", "core2", "")) +@@ -22,4 +23,7 @@ ,("aarch64-apple-ios", ("e-m:o-i64:64-i128:128-n32:64-S128", "generic", "+neon")) ,("i386-apple-ios", ("e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128", "yonah", "")) ,("x86_64-apple-ios", ("e-m:o-i64:64-f80:128-n8:16:32:64-S128", "core2", "")) -- 2.19.1 --8t9RHnE3ZwKMSgU+-- From owner-freebsd-haskell@freebsd.org Mon Oct 15 08:32:45 2018 Return-Path: Delivered-To: freebsd-haskell@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3FC410D3904 for ; Mon, 15 Oct 2018 08:32:44 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E2468A758 for ; Mon, 15 Oct 2018 08:32:44 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pl1-f179.google.com with SMTP id 30-v6so8926376plb.10 for ; Mon, 15 Oct 2018 01:32:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FxA+/IfP5XzPXP14ijcoK0F4iyxlX0fcDVT9P0vZZxE=; b=ie2eXDOc74K7kqKIe81/upGUajBbDmySYJvMfAbEl2BB/ocrOl7ZFl70dkzfbCdKFU NFNq4jjwaLEvTTB4pv2bnSdRzk1TPIvBzO2bHGpg3v4mSijE1M5LAvJh3qgSG+K4GmxS yEEzVnclLmq3ujdUk1NThE7EY4QK+rtFn/6TlQkkZt4stD2Ek2liXwV9SB+5IZQhbZRK SFxzKFCDAVtW4XS2R+tFtBJbWFOxit1yTxHeDQTHZ2ktnx6sPB0AlL6Q7v1X06VeiMqE 0KSX7AiPyGBbgIlG9/oe5lCHUviGt+jMZuL8MmEv/ncCLGlmnPpeekqLX3z+vYkqHkrw 12Og== X-Gm-Message-State: ABuFfoi1C56YaNZLEHMgx9BA7IrwgGthKxjRyEecd1e7erpK3abDAYRL dveeMD6TGxYji+k6dc6/OM3XUIy5SMI= X-Google-Smtp-Source: ACcGV60zXITV9JcbHkfuzLOPvbOB0c/iGuQoaOUR6jq0DIVYr/k4mqv3TTwrpgY3zGk38QgovfeCIg== X-Received: by 2002:a17:902:74c1:: with SMTP id f1-v6mr4532092plt.99.1539592363199; Mon, 15 Oct 2018 01:32:43 -0700 (PDT) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com. [209.85.214.170]) by smtp.gmail.com with ESMTPSA id f68-v6sm13822255pfe.143.2018.10.15.01.32.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 01:32:43 -0700 (PDT) Received: by mail-pl1-f170.google.com with SMTP id q17-v6so8940685plr.8 for ; Mon, 15 Oct 2018 01:32:43 -0700 (PDT) X-Received: by 2002:a17:902:2de4:: with SMTP id p91-v6mr15987802plb.148.1539592362592; Mon, 15 Oct 2018 01:32:42 -0700 (PDT) MIME-Version: 1.0 References: <20181015080640.GA983@straasha.imrryr.org> In-Reply-To: <20181015080640.GA983@straasha.imrryr.org> From: Gleb Popov Date: Mon, 15 Oct 2018 11:32:15 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Updating ports to GHC 8.4.4? To: freebsd-haskell@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-haskell@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: FreeBSD-specific Haskell issues and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 08:32:45 -0000 On Mon, Oct 15, 2018 at 11:06 AM Viktor Dukhovni wrote: > The Haskell project has just released GHC 8.4.4, which is a bugfix > release for 8.4.3 fixing non-trivial bugs: > > > https://mail.haskell.org/pipermail/haskell-cafe/2018-October/130090.html > > Is anyone planning to update the FreeBSD port? If so, please > consider the attached additional patches to the port "files" > directory. > > I contributed the improved OSMem.c upstream, but this has only been > merged into GHC 8.6.x, and yet this also win for 8.4, and I've been > using it intensively in 8.4.3 (my code runs for 4.5 hours allocating > a cumulative 4.6TB of memory). In addition I'm adding a missing > LLVM target for amd64. > > The attached files are patching patches, I hope that's OK. If > there's some other form in which to make these available, please > let me know. > Took that into account. I'm going to update the port this week. Thanks for working on this! > -- > Viktor. > _______________________________________________ > freebsd-haskell@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-haskell > To unsubscribe, send any mail to "freebsd-haskell-unsubscribe@freebsd.org" > From owner-freebsd-haskell@freebsd.org Mon Oct 15 17:23:00 2018 Return-Path: Delivered-To: freebsd-haskell@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 818EC10C29E2 for ; Mon, 15 Oct 2018 17:23:00 +0000 (UTC) (envelope-from yourinfowithuss2@yourinfowithuss.com) Received: from sonic306-27.consmr.mail.ne1.yahoo.com (sonic306-27.consmr.mail.ne1.yahoo.com [66.163.189.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3D287CD19 for ; Mon, 15 Oct 2018 17:22:59 +0000 (UTC) (envelope-from yourinfowithuss2@yourinfowithuss.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1539624179; bh=62tMqBSmxSyW+o4M0O9zA4gSiCIkOEUd0fquZjHMOsc=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=Zy+8Z7WJHUvH8i0p5zJA3ukKUSEhfIkQV7XcBr8oVq0uG/ZAuU4IrguolNWJQ8hAdHleLJF1gwUQ4uFSDRlIz7PZzTZww2SH4n23XTqAzx/DQfJ7qppcYQtINeL3e+c2UHcg9J6iUKFnPD2tYZD1OpiGd9Ot8rlPl/eursN+88Y5NSUaV2t6d77LUxHGXaicenh20+Xtx6fHkXdq0IiYEP17G6GwcjbFprgc1enN/PGuBdwfqIZuyjSh6UJCyJgvvMuqxO0eNFo8ApIADpZb5alsnAB2L6KJF6s6n1Kfw2UpLR1kMBSp7frTqvVPYj49SgWzYj1v0knZa9WrC6gPXQ== X-YMail-OSG: X1WSOvkVM1ln6z6EVIUWeSDVPo9vFoc8p3wPxLvLYZxoUc8EWfXcHegVCd_Trki bXXDySen3kQ5LFtYCO..fEeGScZn7JhuhatMbJHCErm2DY3whmzdxf4Bww0ENMauhCz0s3HZ1us4 Fs0Up8kd9_yAnfUA4oSawzzJVhLpkfTaEuFX3f.vjir1R.gGaxc1q8j0syX52euUwydRmIK.YCGM ShMLiRwd1JNm5LmoX6Ud5PGp2Zf4Jcs8ZZ9V1MKuQBTqLSvTmSVawQ4jR5LtInFFlEGJE3jAscaO 7G3XLMfZz2YpHyiv355Ka8kJGj3mHDanVx7AC.xcQuZyKf.1RvcJyUMlcLJN5pnDzOc2fleSbaOg uD9IskjpW.AN6.R83dCrqQd26xDCj6NmGeWtLLpg9UF2abm98RuMczDz1LEV4nxmwd1kZxFSmWdN UWPjfVamGtuAqWIeV6G8hzhTvRpKWg4XHIqh.VPOFzpTYsC8sAfm3efsfhnSeNsHOzNWt13o.o8L UNBLkVNbcsxsiWiFYZ.0J.COY8s6FY.mGpOlXCi33FUGlWAg4w3dZAN.dO0FhavvuSl4T3kYS9tm NKjcu2f99AS6Vo5w1TBkGlzFqKOIhThTPqOAQydtnb6WNDjC3SyzirbjfllLiYm.Blus.Mg5r22X Lndzz4bZxOG1hpsLcGYSLvor0eO1k3oKWPWFSPeh4uBWVWx0E04xR9XBbhRJs_qLEflLLxtlsLRj wV_XE8o9MTSVlFukijvIfAemh6M2JL6PSTv_afXn9b8LfNIz142XXDErUYqWvrkocJyIEmt1k1br aoObL7pv9gLir4KKyL.jIuVQ0xj7IR.1FVQIBhuKk4.OShaV16PT5RieMOi1i85hnsuR1Z_PQO40 MjR75_xU9bO5stX7XNRO7OrXqF_ZgSxtupf8Muc75ozEGfV1apPmluvRRFhs2lW5V__86L_M_zUS B.oUWDvDKTgne5dZCRmYZ2Pq2vk2.aMr.4qd4Pk5XfiHmO84dHxIohgV95leqlGa4P5h1XvOdl7U drwUIymlktuZ.8Tw.160wh6_gjDNcLlbeVlQwgyhqaAmu6Ek2BImIKuKH420Bmf1ipuqpJ7scmu2 STrQ2nJFw1zF.9qWYkQ71rwqcJy2HPGbZfJoaj_.F97a2cA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Mon, 15 Oct 2018 17:22:59 +0000 Received: from 49.207.48.237 (EHLO Admin10PC) ([49.207.48.237]) by smtp415.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dc5a10abc3758130e505cf03a459e35f for ; Mon, 15 Oct 2018 17:12:46 +0000 (UTC) From: "Maggie Neil" To: References: In-Reply-To: Subject: RE: Design-Build Attendee Portal List 2018 Date: Mon, 15 Oct 2018 12:12:42 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdRWcLaqFOWBxk8nSluI/2sxOG71QwAACFSAAAA9mzAAABjLEAAAF7jgAAAb3mAAACGJEAAAABRwAAAAARAAAAAEQAAAAANAAAAAA3AAAAAEcAAAAANwAAAAA6AAAAADoAAAAAOgAAAABNAAAAADwAAAAAMAAAAAAwAAAAAEMAAAAANgAAAAA2AAAAAEkAAAAAOQAAAABMAAAAAD8AAAAAMgAAAABFAAAAAEgAAAAAOwAAAABOAAAAAEIAAAAANQAAAABIAAAAAEsAAAAAMQAAAABEAAAAAEcAAAAAOgAAAABBAAAAAEQAAAAARwAAAABNAAAAAEAAAAAANwAAAABNAAAAAEAAAAAARgAAAABJAAAAAEAAONri3Q Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-haskell@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: FreeBSD-specific Haskell issues and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 17:23:00 -0000 Hi I am just doing a follow up with my previous email to check whether you are interested in our Attendees Lists. Could you please let me know your thoughts? In turn, I would be happy to share the number of contacts we have and pricing for the same. Thank you and I Look forward to hearing from you. Regards Maggie Neil Event Data Specialist From: Maggie Neil [mailto:yourinfowithuss2@yourinfowithuss.com] Sent: Thursday, September 27, 2018 10:09 AM To: 'freebsd-haskell@freebsd.org' Subject: Design-Build Attendee Portal List 2018 Hi Hope this email finds you well! I am writing this to check if you would be interested in acquiring a list of DESIGN-BUILD CONFERENCE & EXPO Annual Conference - held on November 07-09, 2018. We have recently updated our Design-Build file and we can help you with any Design-Builders, Architects, Engineers, General & Specialty Contractors, Program and Construction Managers, Finance, Private Sector Owners from industries of all types, Operators, Administrators, Purchasing Departments, Power/Energy, vice president & C - Level Executive and many more. The list can be used for multi-channel marketing: * Email campaigns * Direct mail marketing * Tele marketing * Social media campaign etc. Information fields include Contact name, Company name, Job Title, Company Mailing address with Zip Code, Phone Number, Fax Number, SIC Code, Industry Classification, Website URL and contact person verified business email address and LinkedIn Profile. Please let me know if you are interested and I shall help you with the Price and next steps. Best Wishes, Maggie Neil Event Data Specialist