Re: Does newByteArray clear?
On 27/08/2020 02.56, Bertram Felgenhauer via Glasgow-haskell-users wrote: > David Feuer wrote: >> I'm looking to play around with an array-based structure with >> sub-linear worst-case bounds. Array is pretty awkward in that context >> because creating a new one takes O(n) time to initialize it. Is that >> all true of newByteArray, or can I get one with arbitrary garbage in it >> for cheap? > > newByteArray# does not actively clear memory. > > However, for large arrays, I think the memory is likely to be freshly > allocated from the OS, and the OS will have cleared it for security > reasons. > Not sure how common it is in practice, but it's worth noting that OS'es should be able to clear freed memory as a background process, so that they don't have to do it on demand at the precie point of allocation. Of course this depends on memory churn, etc. etc., so it's not exactly guaranteed even if the OS supports it. Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
On 10/08/2020 23.22, Tyson Whitehead wrote: > On Mon, 10 Aug 2020 at 03:12, Bardur Arantsson <mailto:s...@scientician.net>> wrote: > > Once you have that bit set up, you can copy *most* of the libraries > ..so's you're using to that folder on the install target and they'll be > loaded from there. (Copying libc.so is ill advised, but most of the > others will work just fine. I believe ld-linux-... is also never ever > loaded from there since that *is* the dynamic loader.) > > > Not 100% certain, but I think the issue with libc may be that it may be > somewhat tied to the ld-linux. > > You can actually copy everything, including ld-linux, though. You then > invoke the program via ld-linux (it's actually an executable -- see the > ld..so page) > > ./ld-linux-x86_64.so.2 --library-path > ... > Hm, yes I was vaguely aware of this ability to invoke the loader directly, but IIRC the most immediate problem with glibc has always been that the nsswitch.conf plugins (which are always dynamically loaded) are strictly tied to the exact gblic version. I guess if you copy them too, it should work, but the issue is that there may be ones on the user's system which aren't present on the CI/build system... > If you wrap your binaries with a shell script it is actually pretty > clean (make sure to exec so you don't windup with the shell sitting > between parent and childs that can cause some subtle issues) Yes, this is also a good way to do it and doesn't require messing with the build setup. > > The only real breakage I've seen from this is when you try and run on > too old of a kernel for your libc or the remote system has an unusual > nsswitch plugin you didn't provide. Ack Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Linking completely statically
On 09/08/2020 14.50, Volker Wysk wrote: > Hi! > > I know of the command line argument "-static". But this only affects > the Haskell libraries. I want to link some programs completely > statically, no external libraries needed. > > When just linking with "-static" I still have those dynamically linked > things: > > desktop ~/bin $ ldd sicherung > linux-vdso.so.1 (0x7ffdab53f000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 > (0x7f3633da) [--snip--] > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 > (0x7f3633ce3000) > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 > (0x7f3633cd7000) > libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 > (0x7f3633ccb000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > (0x7f3633ad9000) > /lib64/ld-linux-x86-64.so.2 (0x7f3633f0c000) > > > Is it possible to link the remaining libraries statically too? > As Brandon already mentioned, linking glibc statically is not really supported (by glibc!), but what you can do is bundle a few of the .so's together with your binary and use RPATH to help your executable find them at load time (well, dynamic link time). A project of ours where we do this is using Stack, so I can only really provide info on doing it with Stack, but hopefully you can adapt to whatever you're using: We added ld-options: - -Wl,-rpath,$ORIGIN/../lib to the 'executable' portion of the package.yaml. This instructs the dynamic loader to look for libraries in '../lib' relative to the executable's location. You can pick whatever path you want there. Once you have that bit set up, you can copy *most* of the libraries .so's you're using to that folder on the install target and they'll be loaded from there. (Copying libc.so is ill advised, but most of the others will work just fine. I believe ld-linux-... is also never ever loaded from there since that *is* the dynamic loader.) (Of course a possibly more robust version of this is to just bundle everything into a container of some sort, but that may be a bit excessive for your needs.) HTH, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
On 07/09/2016 09:09 AM, C Maeder wrote: > The asymmetry that you mention is already apparent for (Haskell98) infix > expressions, i.e. when "composing" lambda- or if-expression: > > (if c then f else g) . \ x -> h x > > Parentheses around the last argument of "." do not matter, but > parentheses around the first argument make a real difference (that the > type checker will not detect)! > What I'm reading here is essentially "Parser already does non-obvious thing" ===> "Adding more non-obvious things is fine!" This is simply bad reasoning, and I'm not sure why a number of people are saying it. Am I missing something? Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
On 07/04/2016 12:31 PM, Akio Takano wrote: > Hi glasgow-haskell-users, > > I have written a wiki page about a proposed extension called > ArgumentDo. It's a small syntactic extension that allows "do" > expressions, lambdas and a few other kinds of expressions to be used > as function arguments, without parentheses. > > https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo > > Any feedback is appreciated. In particular, since the idea has > received mixed support (see the "Discussion" section on the wiki > page), I'd like to make sure that there is enough support for this > feature to justify an implementation in GHC. > -1 Reasons have already been given in previous threads on this. However, I'd point especially to the fact that people don't *agree* that this is more readable as a very strong point against -- regardless of whether any one individual thinks it's more readable or not. The point is the there seems to be a lot of disagreement -- that indicates to me that this cannot by definition be a "clear win"[1]. Disclosure: I personally find it less readable because of the implicitness. Implicitness which has a non-trivial probability of affecting semantics is bad in my book. Frankly, if it came to it, I'd rather just remove $ and deal with the parentheses. Regards, [1] Which I should think the barrier to extensions should roughly be :). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: RFC: Removing the `-hb` profiling option
On 05/06/2016 11:04 AM, Erik de Castro Lopo wrote: > Hi all, > > After a bit of rather tedious and frustrating debugging I came to the > realisation that the code for the `-hb` profiling option is not thread > safe. See https://ghc.haskell.org/trac/ghc/ticket/12019 > > This gives us an opportunity to simply remove it instead of fixing it. > If there is anyone that thinks this future is really useful (ie more > useful than the other profiling modes) then I'm willing to fix it. > But if noone would miss it. I'd much rather remove it. > I can't say I've ever used the option, but just to inform discussion... Do you have any guesstimate[1] of how much effort it would take to fix vs. just removing? Unless there's a reasonably clear idea of how much effort there's going to be in it[2], I usually err on the side of removal *unless* a really good case can be made. Regards, [1] As ballpark as you like. Even a ratio would work, I think. [2] Which tends to not be the case for threading-related issues. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Typing pattern synonyms
On 09/30/2015 08:10 PM, David Feuer wrote: > The Eq constraint is needed to support pattern matching, the raison d’être > of pattern synonyms. I'm pretty sure the reason you need > ScopedTypeVariables for your second example is that GHC only allows pattern > signatures with that extension enabled. Once upon a time there was a > separate PatternSignatures extension, I believe, but not any more. Perhaps ScopedTypeVariables by default (or only?) would be relevant for the revamped[1] Haskell' committee? Would there be any actual downsides? It's always seemed to me that ScopedTypeVariables was the way it should have been from the start (given perfect foresight). Regards, [1] http://permalink.gmane.org/gmane.comp.lang.haskell.prime/3965 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: RFC: Dropping Windows XP support
On 2014-11-13 15:25, Bulat Ziganshin wrote: Hello Austin, Friday, November 7, 2014, 9:16:22 PM, you wrote: For one, Microsoft doesn't support XP anymore, so most people are moving off it anyway. 'Soon' even XP Embedded will be obsoleted. at the end of http://freearc.org/Statistics.aspx page you can find stats about OS used by ysers of my program - archiver written in haskell. these are 14% of *geeks* using the l;atest alpha version (stable version of my program ddoesn't report this parameter) so dropping XP support means that newer GHC can't be used anymore to compile general-purpose programs targeting large user audience I'm not sure I understand the version numbers, but it seems 95.46% of your users a version from before June 26, 2010. How likely are they to upgrade if they haven't upgraded since 2010? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-05-30 11:00, John Meacham wrote: JHC has the feature that Graphics.UI.GTK.Button can live in any of: Graphics/UI/GTK/Button.hs Graphics/UI/GTK.Button.hs Graphics/UI.GTK.Button.hs Graphics.UI.GTK.Button.hs It lets you have deep module hiarchies without deep directory hierarchies and is not terribly surprising as behaviors go. This sounds much more appealing idea in that all the necessary information is still in the file system and not tangled up in the build specification (compiler flags). Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-04-25 15:17, Simon Marlow wrote: I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. -1, too complicated for very little benefit ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-04-25 18:52, Edward Kmett wrote: I check out and work on projects on a bunch of machines, so it is important that I can just pull with git and go. AFAIK, git doesn't understand them won't build symlinks for me, so it'd just become another setup step for very marginal benefit, and another thing to .gitignore. Git handles symlinks just fine. (Unless you're on Windows, I guess. I have no idea what it does there.) Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-04-25 15:17, Simon Marlow wrote: [--snip--] -1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Desugaring do-notation to Applicative
On 2013-10-02 20:13, Reid Barton wrote: On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett ekm...@gmail.com wrote: That is admittedly a pretty convincing example that we may want to provide either a LANGUAGE pragma or a different syntax to opt in. I suppose the Applicative desugaring can reliably be disabled by adding a syntactic dependency on previous variables, like [ (x, y) | x - [1..3], y - const [1..1000] x ] so as far as I'm concerned it's sufficient if the Applicative desugaring is opt-in on a per-module basis, without a separate syntax for Applicative vs Monad do-notation/comprehensions. That seems like an easily-overlooked and IMO too-subtle way to saying hey, GHC, don't do the applicative desugaring in this particular place. Those who opt in can be expected to understand and deal with this sharing issue if it affects them. (They pretty much have to understand it already, if they are compiling with optimizations.) I don't think it's a about understanding -- not all READERS of the code could necessarily be expected to have the same expertise (or level of carefulness) as the writer of the code. This could lead to subtle bugs arising during maintenance. Therefore it would seem a good idea to me to be explicit about the distiction with ado vs. do (or similar) -- not sure about how the distincation should be made in the comprehensions, but I'm sure *something* explicit can be worked out. I mean, is a single extra letter really a burden? Regards, Bardur ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 02/12/2013 09:37 AM, Simon Marlow wrote: On 11/02/13 23:03, Johan Tibell wrote: Hi, Of course we do also make well-intentioned changes to libraries, via the library proposal process, and some of these break APIs. But it wouldn't do any harm to batch these up and defer them until the next API-changing release. Indeed. It might even be preferable to just have one huge breakage every year than having lots of minor breakages which require updating packages (and dependencies). At least you'll feel you're getting your money's worth. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: Adding support for an API-since-version-attribute to Haddock?
On 09/04/2012 12:56 PM, Herbert Valerio Riedel wrote: Hello Haskellers, I've been wondering whether it might be useful to add a feature to Haddock similar to what can be found in other API documentation systems, specifically an optional parseable since-attribute, declaring the last package version when the associated definition/symbol was introduced or its semantics modified. +1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
On 07/10/2012 12:51 PM, malcolm.wallace wrote: Also, it is more likely to be a buggy instance of Eq, than a real loss of referential transparency. Speaking of which... would it be remiss of me to mention the elephant in the room, namely the Eq instance for Float? AFAICT there is no possible way for a Float value to fulfill the Eq type class requirements, so why is it an instance? (I'm thinking of the weird Nan/Infinity behvaior primarily). Is there *really* such a huge amount of code out there that relies on an Eq (or Ord for that matter!) instance for Float? If so... shouldn't that code be fixed rather than being subtly buggy? Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote: On 07/09/2012 09:52 PM, Twan van Laarhoven wrote: On 09/07/12 14:44, Simon Marlow wrote: I now think '\' is too quiet to introduce a new layout context. The pressing need is really for a combination of '\' and 'case', that is single-argument so that we don't have to write parentheses. I think '\case' does the job perfectly. If you want a multi-clause multi-argument function, then give it a name. There is an advantage here for \of in favor of \case, namely that of already introduces layout, while case does not. Do you think that adding \ + case as a layout herald would complicate the language spec and/or confuse users? Because it certainly does not complicate the implementation (there is a patch for \case already). Just being anal here, but: The existence of a patch to implement X does not mean that X doesn't complicate the implemenatation. ... as you were. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: containing memory-consuming computations
On 04/19/2012 12:45 PM, Herbert Valerio Riedel wrote: Hello GHC Devs, But I'm missing a similar facility for constraining the space-dimension. In some other languages such as C, I have (more or less) the ability to check for /local/ out-of-memory conditions (e.g. by checking the return value of e.g. malloc(3) for heap-allocations, or by handling an OOM exception), rollback the computation, and be able to Just a minor point which may be of interest: Many operating systems (including Linux by default) overcommit memory, so there is in fact no guarantee that memory returned by malloc() will in fact be usable under memory pressure. So, getting a non-NULL pointer from malloc() is not a guarantee. (There are good reasons for this behavior.) Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
