Re: Default value for numCapabilities?

Hello Dimitry, Tuesday, April 27, 2010, 8:09:49 PM, you wrote: a few months ago i asked SimonM about using all cores by default, but he said that it dramatically reduces performance in some cases > Hi, > As a followup to the discussion [1] about the portable way to find the > number of CPUs/cor

Re[2]: -O vs. -O2

Hello Duncan, Sunday, May 9, 2010, 1:50:31 AM, you wrote: > It should be -O1 for default/balanced optimisations and -O2 for things > involving a bigger tradeoff in terms of code size or compile time. so cloning gcc policy may be a good choice. -O2 is the best optimization that "guaranteed" to ma

Re[2]: [Gtk2hs-users] ANNOUNCE: GHC 6.12.3 Release Candidate 1

Hello Axel, Thursday, May 27, 2010, 8:42:08 PM, you wrote: > - you use -threaded to compile your program > - you only use postGUISync and postGUIAsync from threads different to > the Gtk2Hs thread > Is this true? If yes, I'll give you an elaboration on how threads are > supposed to work in Gtk+

Re: GHC.IO.Device and "ready" method?

Hello Dimitry, Friday, June 25, 2010, 7:06:31 PM, you wrote: > As a more general question, are GHC Handles (and underlying > implementations of GHC.IO.Device and GHC.IO.BufferedIO) expected to be > thread-safe? i think so. i consider threads as control structure and your question looks for me th

Re[2]: Lazy IO and asynchronous callbacks?

Hello Evan, Friday, July 9, 2010, 3:01:28 AM, you wrote: > There may very well be a better way to do this, but it definitely > feels better to me than relying on unsafeInterleaveIO magic. Your > chan reader has to be in IO, but that's as it should be and you can > still pass the chunks off to pu

Re[2]: HEAD: Deterioration in ByteString I/O

Hello Daniel, Thursday, September 9, 2010, 3:28:04 AM, you wrote: > - bytestring allocates a 32K buffer to be filled and asks ghc for 32760 > bytes in that buffer > - ghc asks the OS for 8192 bytes (and usually gets them) btw, we made benchmarking that shown that the most efficient read/write ch

Re[2]: Unicode windows console output.

Hello Max, Wednesday, November 3, 2010, 1:26:50 PM, you wrote: > 1. You need to use "chcp 65001" to set the console code page to UTF8 > 2. It is very likely that your Windows console won't have the fonts > required to actually make sense of the output. Pipe the output to > foo.txt. If you open th

Re: Rigid types fun

Hello Mitar, Friday, November 5, 2010, 12:45:21 PM, you wrote: > from <- newChan > for <- newChan > let nerve = Nerve (Axon from) (AxonAny for) create = do from <- newChan for <- newChan return$ Nerve (Axon from) (AxonAny for) main = do nerve <- create ... --

Re[2]: Rigid types fun

Hello Mitar, Friday, November 5, 2010, 2:08:52 PM, you wrote: > I would like to call it like "create (Axon undefined) (AxonAny > undefined)" and get in that case "Nerve (Axon a) (AxonAny b)" as a > result. If I would call it like "create (AxonAny undefined) (AxonAny > undefined)" I would get "Ner

Re: 6.12.3: hs_add_root crashes

Hello Bulat, Monday, November 15, 2010, 4:20:14 PM, you wrote: > hs_init(NULL, NULL); > hs_add_root(__stginit_Main); > but it crashes on hs_add_root call. what may be source of problem? just in minutes after presing Send i've found reason of problem. it was due to NULLs passed to hs_ini

6.12.3: hs_add_root crashes

Hello , ghc 6.12.3. i use the following code to initialize my haskell dll: extern "C" { #include "HsFFI.h" void __stginit_Main(); void haskell_init (void) { static bool initialized = FALSE; if (!initialized) { initialized = TRUE; hs_init(NULL, NULL); hs_add_root(__stginit_Main)

Re: Parallel, Incremental Linking

Hello John, Tuesday, December 7, 2010, 11:54:22 AM, you wrote: > The bottleneck for building on my multi-core machine is ld, which afaik, there was some alternative linker, at least for linux systems -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___

Re: Behavior of the -H RTS option, possible doc/impl mismatch

Hello Akio, Wednesday, February 16, 2011, 11:24:31 AM, you wrote: > ./a.out +RTS -N7 -A256M -H2G uses around 7 GBytes of memory > ./a.out +RTS -N7 -A256M -H6G uses around 13 GBytes of memory ghc uses copying GC by default - when heap overflows, it copies all the live data to the new heap and use

Win64 support

Hello glasgow-haskell-users, the one thing that users of my program asked most is the Win64 support: http://code.google.com/p/freearc/issues/list . we have waited for a several years, but it's still not in GHC, so i want to know at least: why it's not going forward? can we have unregisterized buil

Re[2]: Win64 support

Hello Ian, Wednesday, May 9, 2012, 7:12:03 PM, you wrote: > The Industrial Haskell Group has been funding work on the Win64 port. It > will be released with GHC 7.6. wow! what is the current state, when it planned to be released, how it's implemented (gcc/mingw64?) ? may be this port has its own

Common syntax for casing/matching (Re[2]: Call to arms: lambda-case is stuck and needs your help)

Hello wagnerdm, Thursday, July 5, 2012, 7:22:38 PM, you wrote: >> After 21 months of occasional arguing the lambda-case proposal(s) is this reminded me old joke about PL/I: camel is the horse created by committee i propose to return back and summarize all the requirements we have in this area.

optimizing StgPtr allocate (Capability *cap, W_ n)

Hello Glasgow-haskell-users, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rts/sm/Storage.c#L680 if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdesc

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Title: Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590 Hello Brandon, Wednesday, October 1, 2014, 1:02:54 AM, you wrote: On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace wrote: How about doing the honest thing, and withdrawing both packages in

Re: RFC: Dropping Windows XP support

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

Re: ANNOUNCE: GHC version 6.6.1

Hello Ian, Thursday, April 26, 2007, 3:22:23 PM, you wrote: > The (Interactive) Glasgow Haskell Compiler -- version 6.6.1 can you please include in win32 distro c++ compiler, as it was done before and as it requested by trac ticket http://hackage.haskell.org/trac/ghc/ticket/1024 ? to be exac

Re[2]: ANNOUNCE: GHC version 6.6.1

Hello shelarcy, Thursday, April 26, 2007, 6:54:40 PM, you wrote: > Hello, Bulat, > On Thu, 26 Apr 2007 22:07:47 +0900, Bulat Ziganshin > <[EMAIL PROTECTED]> wrote: >> can you please include in win32 distro c++ compiler, as it was done >> before and as it reque

Re[2]: ANNOUNCE: GHC version 6.6.1

Hello Duncan, Saturday, April 28, 2007, 9:58:18 PM, you wrote: >> can you please include in win32 distro c++ compiler, as it was done >> before and as it requested by trac ticket >> http://hackage.haskell.org/trac/ghc/ticket/1024 ? > Is it just me who thinks this is a silly idea? Why should GHC

Re[2]: ANNOUNCE: GHC version 6.6.1

Hello Albert, Sunday, April 29, 2007, 2:51:24 AM, you wrote: >> Is it just me who thinks this is a silly idea? Why should GHC include a >> C++ compiler? > .NET literates, will benefit from the many libraries available in .NET. > Can we also include a .NET runtime, a .NET documentation suite, all

Re[4]: ANNOUNCE: GHC version 6.6.1

Hello Duncan, Sunday, April 29, 2007, 8:00:56 PM, you wrote: >> java/c# libs can't be used with current ghc, so 99% of > Making it possible to use Haskell in mixed language projects with C++ > and Java how ghc/mingw can be used with java? :) -- Best regards, Bulat

Re[6]: ANNOUNCE: GHC version 6.6.1

Hello Duncan, Monday, April 30, 2007, 10:11:09 AM, you wrote: >> how ghc/mingw can be used with java? :) > I expect it's quite tricky! :-) > I'm not claiming it works or is easy, I was just commenting that making so, you agree that 99% of foreign-language libs that can be used with ghc/mingw a

Re: GHC -O2 and unsafePerformIO

Hello Neil, Wednesday, May 2, 2007, 7:00:05 PM, you wrote: > {-# NOINLINE wrapIO #-} > wrapIO x = unsafePerformIO (x >>= return) -fno-cse ? it's usual company for unsafePerformIO+NOINLINE :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] __

Re[2]: isSpace is too slow

Hello Ketil, Monday, May 21, 2007, 12:43:16 PM, you wrote: isSpace :: Char ->> Bool > isSpace = isSp . ord > isSp c | c <= 13= c >= 8 -- \b..\r >| c <= 127 = c == 32 -- ' ' >| c <= 255 = c == 0xa0 -- nbsp >| otherwise = iswspace(..) that's great but array-ba

Re[2]: readArray is faster than unsafeRead

Hello Scott, Wednesday, May 30, 2007, 1:42:22 AM, you wrote: > I've included your implementation for comparison, as well as a simple > pure matrix multiplication function, but I'm having trouble tracking > them down in the profiling. I think all of their cycles are being > counted under main, but

64-bit windows version?

Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.or

Re[2]: 64-bit windows version?

Hello skaller, Tuesday, June 19, 2007, 8:15:19 PM, you wrote: >> > are you plan to implement 64-bit windows GHC version? > Why do you need mingw? What's wrong with MSVC++? really! Simon, how about unregisterised build? skaller, is *free* 64-bit msvc (or any other windows c++ compiler) available

Re[2]: 64-bit windows version?

Hello Simon, Wednesday, June 20, 2007, 11:51:34 AM, you wrote: >> really! Simon, how about unregisterised build? > Unregisterised would still need a C compiler capable of generating 64-bit > code. > Are you talking about using the MS compiler for that? Certainly possible, > but > I'm not sur

Re[4]: 64-bit windows version?

Hello skaller, Thursday, June 21, 2007, 7:06:09 AM, you wrote: >> generally speaking, people want to use 64-bit code in order to work >> with much larger data space, overall speed may be better than using >> 32-bit version with 2gb limit > With x86_64, 64 bit programs are usually faster than 32 b

Re[2]: 64-bit windows version?

Hello Peter, Monday, June 25, 2007, 9:35:31 PM, you wrote: >> Maybe some gcc mimicing cl wrapper tailored specifically for GHC >> building system could help? One more layer of indirection, but >> could leave ghc driver relatively intact. > That's a good idea! there is possibility that such dr

Re[2]: RTS/Garbage Collector idea

Hello Daniel, it seems like a good proposal for general-purpose library Friday, July 6, 2007, 4:12:49 AM, you wrote: > Presumably it's possible to do a piece-meal app-level hash consing of values > by defining an appropriate identity memoisation. Though maybe the optimiser > is so cunning it fi

Re[2]: Prefix form of unboxed tuple

Hello Simon, Friday, July 6, 2007, 6:57:26 PM, you wrote: > Another feature I'd like is for unboxed tuples to be more first > class. For example, we don't currently allow > f :: (# a, b #) -> ... one particular feature i wanted in my fast io/serialization libs is ability to return unboxe

Re[2]: [GHC] #1338: base package breakup

Hello GHC, Friday, July 6, 2007, 10:04:05 PM, you wrote: > #1338: base package breakup > Not clear what to do with these: > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph >

Re: ForeignPtr and -threaded

Hello PHO, Sunday, July 22, 2007, 5:36:27 PM, you wrote: > [2] Foreign.ForeignPtr > The following code prints nothing when it isn't linked with -threaded > RTS, but when it is, it *sometimes* prints "called" but not always. > import Foreign.Marshal.Alloc > import Foreign.Ptr > import Foreign.Fo

Re[2]: Annotation for unfolding wanted

Hello Simon, Tuesday, July 31, 2007, 1:22:14 PM, you wrote: > GHC never inlines recursive functions. Why not? Because doing so > exposes a new inline opportunity. How many times would you like it inlined? > Not forever, I assume! really, state of things in this area is not pleasant. making

Re[2]: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?)

Hello Isaac, Saturday, August 4, 2007, 4:01:18 AM, you wrote: > Inserting a preemption test in non-allocating loops seems like a good > idea to me (I hate the invisible threat that my program might not thread > as threading should work)... any idea how bad the performance impact > could be with

Re[2]: Hackage and GHC 6.8

Hello Thomas, Monday, September 24, 2007, 6:42:11 PM, you wrote: > This is not a pretty solution and also has the problem of incorrectly > dealing with changes to the base interface. This, IMO, is due to > keeping the name 'base' instead of opting to clarify the > incompatibilities by choosing "

Re[2]: type families + GADT = type unsafety?

Hello Stefan, Friday, September 28, 2007, 1:10:09 AM, you wrote: > data Foo a where >A :: Foo Int >B :: Foo Bool > becomes > data Foo a = (a ~ Int) => A | (a ~ Bool) => B hm :) this looks like my quasi-proposal of unifying data and function definitions still has some meaning. i propos

Re: 6.8.1-toTest

Hello Serge, Saturday, September 29, 2007, 1:53:48 PM, you wrote: > Maybe, you can put the source, for example, > ghc-6.8.1-toTest-September-29.src, > and announce in this list where to download it from sources are archived every day, for example http://www.haskell.org/ghc/dist/current/dist

Re[2]: 6.8.1-toTest

Hello Serge, Saturday, September 29, 2007, 4:35:28 PM, you wrote: > I suspect that > ghc-6.8.0.20070928-src.tar.bz228-Sep-2007 15:59 6.7M > is the last candidate for 6.8.1, because its date is fresh. > Is it ? yes. it is named 6.8.0, not 6.8.1, in order to become "lesser"

Re: Data.Map in 6.8.1

Hello Serge, Saturday, September 29, 2007, 7:38:32 PM, you wrote: > Now, make configure > reports > runghc Setup.hs configure --ghc > --prefix=/home/mechvel/dm/1.06/dm/source/inst > Configuring dumatel-1.6... > In 6.6.1, the report of runhaskell looked better, it wrote on the > scree

Re[2]: GHC benchmarks

Hello Simon, Monday, October 15, 2007, 2:52:10 PM, you wrote: > Right - GC time doubled, which is what we'd expect to see when the resident > data size doubles. The decrease in MUT time is probably due to the extra > registers available, but MUT time would also be affected by the increase in > d

Re[2]: Case of "Language" pragma - bug?

Hello Ian, Wednesday, October 31, 2007, 11:43:47 PM, you wrote: > Currently the lexer looks for them as regexps, e.g. > "{-#" $whitechar* (LANGUAGE|language) { token ITlanguage_prag } standard solution: [l|L][a|A]... -- Best regards, Bulatmailto:[EMAIL PROTECT

6.6.1 installlers

Hello glasgow-haskell-users, i've found that 6.6.1 downloading page ( http://haskell.org/ghc/download_ghc_661.html ) doesn't contain info about availability of Debian, Fedora and SUSE packages. is it possible to add it there? (also for other unices where such packages exist) the reason is that i

Re[2]: GHC 6.8.1 is impressive!

Hello Peter, Friday, November 9, 2007, 8:47:21 PM, you wrote: > -O2 -fno-liberate-case -fexcess-precision > -O2 -fno-spec-constr -fexcess-precision test also with -O2 -fno-spec-constr -fno-liberate-case -fexcess-precision -- Best regards, Bulatmailto:[EMAIL PROTEC

Re[2]: Extensible Records

Hello Stefan, Sunday, November 11, 2007, 2:54:51 AM, you wrote: >> Is there any chance of seeing extensible records in GHC 6.10? > I second this request +1 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskel

Re[2]: Extensible Records

Hello Barney, Sunday, November 11, 2007, 2:34:14 PM, you wrote: > An important application which is made impossible by this approach is i propose to start "Records project" by composing list of requirements/applications to fulfill; we can keep it on Wiki page. this will create base for language t

Re: Binary for Vista 64-bit

Hello Chris, Sunday, November 11, 2007, 4:57:39 PM, you wrote: > Just wondering if a binary for Vista 64-bit will be released? i've asked here June 19. Simon Marlow asked: >The main thing standing in the way of this is the lack of a 64-bit port of >mingw. The latest status update I could find

Re: [Haskell-cafe] Re: some links broken in 6.8.1 documentation

Hello Daniil, Monday, November 12, 2007, 7:56:23 PM, you wrote: > And, if a package is updated between two ghc releases, will the > extralibs tarball be updated (and precompiled binary ghc packages, for > that matter) ? i think it will be bad idea. instead, anyone who need to have latest package

Re[2]: ghc-6.8.1, +RTS -N2

Hello Johannes, Tuesday, November 13, 2007, 12:08:20 PM, you wrote: >> i suggest you to test it on one-threaded CPU too > I just did. The behaviour is identical > (works with -N1, segfaults with -N2) > Any ideas? - Best regards, J.W. no. just publish this into maillist, it's important to ident

win32&ghc: using more than 2gb of memory

Hello is it possible to use more than 2gb of memory for win32 ghc-compiled programs? does anyone checked this? i've found that the following switch should be added to cmdline: ghc ... -optl --large-address-aware but can't check compiled executable if this question was never considered, here is

Re[2]: type equality symbol

Hello Simon, Wednesday, December 5, 2007, 7:05:22 PM, you wrote: > Anyway, while on this subject, I am considering making the following change: > make all operator symbols into type constructors > (currently they are type variables) i like it. will the same apply to the type func

mingw64

Hello Glasgow-haskell-users, are you know about http://sourceforge.net/projects/mingw-w64 ? this project was started just a few months ago, but it already provides downloads to test. the win64 support is very important for my project so please look at it -- Best regards, Bulat

Re[2]: ANNOUNCE: GHC version 6.8.2

Hello Juanma, Saturday, December 15, 2007, 4:24:43 AM, you wrote: > Because what Yitzchak Gale proposed and I seconded does not mean that > getHomeDirectory will not "follow the Windows API", unless very > specifically requested by setting HOME. i'm against this idea. one can setup HOME for some

Re: ForeignPtr performance

Hello Scott, Sunday, December 16, 2007, 11:57:33 PM, you wrote: > My question is: what exactly does GHC.Prim.touch# do? This appears to it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc optimizer that data were accessed so it doesn't free the memory -- Best regards, Bulat

Re[2]: ForeignPtr performance

Hello Simon, Monday, December 17, 2007, 1:33:19 PM, you wrote: >>> My question is: what exactly does GHC.Prim.touch# do? This appears to >> >> it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc >> optimizer that data were accessed so it doesn't free the memory > Yes, exactly.

Re: [Haskell-cafe] Re: #haskell works

Hello Simon, Thursday, December 20, 2007, 4:01:59 PM, you wrote: > Fixing it all properly means some fairly significant architectural changes, > and dropping the via-C backend oh, thank you. from my POV, C backend still may be used together with "non-registerized" compilers. in particular, i hop

Re[2]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Hello Thorkil, Thursday, January 10, 2008, 11:24:16 AM, you wrote: >> I've succeeded in building a binary distribution that uses static >> libraries for gmp and readline. > "GMP is distributed under the GNU LGPL. This license makes the library free to > "Readline is free software, distributed und

Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Hello Yitzchak, Thursday, January 10, 2008, 1:06:12 PM, you wrote: >>> "Readline is free software, distributed under the terms of the GNU General >>> Public License, version 2. >> in short, that means that software compiled with this compiler AND >> distributed to general audience, should have G

ghc 6.6.1 -optl bug?

Hello GHC, sorry, i'm still user of 6.6.1 version the following command: ghc --make -optl-s strips the executable while the following command ghc --make -optl--strip-all has no effect. i made some experiments and it seems that options starting with "--" are not sent to ld at all (you

Re[2]: ghc 6.6.1 -optl bug?

Hello Christian, Friday, January 11, 2008, 4:10:36 PM, you wrote: > Does adding -optl-Xlinker help you? > ghc --make Hello.hs -fforce-recomp -optl-Xlinker -optl--strip-all thank you - it works! -- Best regards, Bulatmailto:[EMAIL PROTECTED] __

Re[6]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Hello Manuel, Thursday, January 17, 2008, 7:49:00 AM, you wrote: >> for me, GMP is much more problematic issue. strictly speaking, we >> can't say that GHC is BSD-licensed because it includes LGPL-licensed >> code (and that much worse, it includes this code in run-time libs) > use of GMP in the c

Re[2]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Hello Isaac, Thursday, January 17, 2008, 8:05:56 PM, you wrote: > (b) is a sufficient condition, but not necessary; there are other ways > to satisfy the license. It's also possible to just distribute, for > example, the .o file(s) and a way to link them with a GMP to get the > final result; th

Re[6]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Hello Yitzchak, Thursday, January 17, 2008, 7:10:54 PM, you wrote: > Wow, I didn't realize that. Now I understand Bulat. In a > project of any serious size and complexity, the use > of static or dynamic linking is often architechted in and > cannot be changed. So LGPL is really bad for a general

Re: Will implicit parameters survive?

Hello Wolfgang, Wednesday, February 6, 2008, 10:24:44 PM, you wrote: > I think that implicit parameters can be very useful for implementing global > variables as described in i everyday face the problems with global variables (that are too global, especial when you going to make your program mul

Re[2]: scope of header files

Hello Jason, Saturday, March 15, 2008, 9:55:38 PM, you wrote: >> Because the Ptr type doesn't indicate const-ness (perhaps it >> should). > If it did, could we read constant strings without > unsafePerformIO? probably no; at least for getArgs it was argued that it should have IO return ty

Re[4]: scope of header files

Hello Jason, Saturday, March 15, 2008, 10:08:31 PM, you wrote: >> probably no; at least for getArgs it was argued that it should >> have IO return type because its result is different from run >> to run > What does getArgs have to do with it? > I'm assuming that reading n elements from a co

Re: Unexpected lack of optimisation in -O0

Hello Neil, Thursday, April 10, 2008, 6:21:38 PM, you wrote: > I was just reading the Monad.Reader, where a Yhc based Haskell > Interpreter states that comparisons against GHCi are "unfair", because > Yhc gains too much benefit from this desguaring. i believe that dictionaries is the most impor

Re: large binary footprint ?

Hello HP, Tuesday, May 6, 2008, 11:00:59 PM, you wrote: > The resulting binary code size is 3.9 Mbytes > I had the impression that it should be of the order > of 500 Kbytes. How can I reach that number ? strip executable. you can just add -optl-s to ghc cmdline -- Best regards, Bulat

Re[2]: large binary footprint ?

ghc -optl-s -o hello -L../lib hello.hs > They both result in a binary size of ~2.5MBytes, > which is about 5 times what I expected (500kbytes). > Have I had the 'incorrect impression' of 500kbytes ? > Thanks > hp > On Tue, 6 May 2008, Bulat Ziganshin wrote

Re: small and compact ghc distribution

Hello leledumbo, Wednesday, May 14, 2008, 11:31:41 AM, you wrote: > I'm a college student and I just want to learn functional programming with > Haskell. No need to access libraries other than GHC rtl (or whatever you > call it). > I already have gcc on my machine, does GHC still need its own? >

Re[2]: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase?

Hello Simon, Thursday, May 15, 2008, 1:31:32 PM, you wrote: > It's hard to tell what optimisation level your libraries were compiled > with. The default setting is -O, but when building binary distributions we > usually set it explicitly to -O2. If you got your binary from another > source, the

Re: Type checker loops with innocent looking associated type synonym

Hello Stefan, Thursday, May 15, 2008, 5:46:57 PM, you wrote: >class ZipWithA a where > type Elem a :: * > Should I report this a bug? Or is it perhaps already been taken care > of in the head? Or am I just plain unreasonable here? :-) afair, the rule of thumb is: please don't report

Re: -optc-O2 considered useful

Hello Don, Thursday, May 15, 2008, 10:47:20 PM, you wrote: > I discovered something today I didn't know. > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. seems that decision to use native backend in ghc -O2 was too early? -- Best regards, Bulat

bug in 6.8.2?

Hello glasgow-haskell-users, i've rather complicated class structure: class BufferData a where instance (FastBufferData a) => BufferData a where class FastBufferData a where instance (Storable a) => FastBufferData a where of course, it's compiled with -fallow-undecidable-instances -fallow-overl

Re: how do I abstract this pattern ?

Hello HP, Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. impossible because these are different types :)) if they return Just result or Nothing - yes, us

Re: ghc compiler <--- ld -R ?

Hello HP, Wednesday, May 21, 2008, 8:21:01 PM, you wrote: > In the linker ld, there is a -R option example of passing option to ld: ghc ... -optl-Xlinker -optl--large-address-aware -optl-Xlinker may be optional -- Best regards, Bulatmailto:[EMAIL PROTECTED] __

Re[4]: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core

Hello Duncan, Friday, May 23, 2008, 11:55:57 PM, you wrote: >> > me too. btw, this already present in jhc. inlining doesn't work in any >> > complex case since recursive functions can't be inlined >> >> GHC inlines recursive functions, too, otherwise it could not turn 'foldl' >> and friends int

Re[2]: Recursive functions and constant parameter closures (inlining/strictness analyzer question)

Hello Simon, Friday, May 30, 2008, 5:30:25 PM, you wrote: may be i don't understand something. isn't it better to do automatic SAT and inline results for every recursive function marked as INLINE? it's how i want to work - just mark with INLINE speed-critical funcs. manual checking that they are

automatically deriving Functor Re[2]: [Haskell-cafe] automatically deriving Map and Filter on datatypes etc.

Hello Neil, Thursday, June 5, 2008, 8:54:51 PM, you wrote: >> PS Why isn't Functor derivable? > Derive can do it: http://www.cs.york.ac.uk/~ndm/derive > I believe that Twan (the author of Functor deriving in Derive) is > trying to get this suggested for Haskell' as a proper deriving. dear GHC

Re: Missing Data.Map library? GHC 6.8.2 under OS X

Hello Thomas, Monday, June 9, 2008, 11:42:40 PM, you wrote: > Undefined symbols: > "___stginit_containerszm0zi1zi0zi1_DataziMap_", referenced from: > ___stginit_Main_ in tst_parse.o > ld: symbol(s) not found add --make to cmdline -- Best regards, Bulatmail

Re: Weekly IRC meeting?

Hello Simon, Friday, July 11, 2008, 1:08:52 PM, you wrote: > Another option is a conference call, but personally I prefer the IRC medium > for this kind of meeting. A conference call could work too, though. i propose to sent every meeting log into cvs-ghc -- Best regards, Bulat

Re[2]: Version control systems

Hello Simon, Tuesday, August 12, 2008, 5:46:59 PM, you wrote: > GHC needs "core libraries" without which it cannot be built. It is > obviously highly desirable that a developer can build GHC with just > one VCS, which suggests that the core libraries should be in git too. > But those same core l

Re[2]: Version control systems

Hello Manuel, Wednesday, August 13, 2008, 4:39:25 AM, you wrote: > Well, its up to you whether you want to validate for other people, but > I don't think that is the right policy. Everybody (including Malcolm) > should validate. as far as we have people validating patches for their platforms (I

Re[2]: Version control systems

Hello Johan, Wednesday, August 13, 2008, 3:43:15 PM, you wrote: >>> - Why does NHC98 break so often? Is it because people are checking in >>> code that is not Haskell 98 compatible? > Can we make sure that these libraries are always built with some > Haskell 98 compatibility flag by GHC so peopl

-optl-s (strip) by default

Hello glasgow-haskell-users, when GHC builds executable, it adds debug info by default. since this info is useless for Haskell and since it significantly increases executable size, will it be better to delete it by default by passing -optl-s option to the linker? another question: by adding " -op

Re[2]: -optl-s (strip) by default

Hello Don, Friday, September 12, 2008, 12:54:22 PM, you wrote: > You can also achieve this by making sure your deployed programs build > with Cabal, *my* programs are built using these opts, how about other haskellers? it comes to surprise that executables contains lot of useless data. second pr

Re[2]: -optl-s (strip) by default

Hello Don, Friday, September 12, 2008, 12:54:22 PM, you wrote: >> when GHC builds executable, it adds debug info by default. since this > You can also achieve this by making sure your deployed programs build > with Cabal, > http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html > No

Re[2]: planning for ghc-6.10.1 and hackage

Hello Simon, Friday, October 3, 2008, 12:55:34 PM, you wrote: > Perhaps we could even go as far as saying "base >= 3.0" is equivalent to > "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give > you a conservative one. I wonder how much stuff would break if we did that. thi

Re[2]: planning for ghc-6.10.1 and hackage

Hello Brandon, Friday, October 3, 2008, 8:53:05 PM, you wrote: > Choose the lowest available version that satisfies all of the > constraints? and bugfixed versions will be never used :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] __

Re: A wiki page for managing the 6.10 handover

Hello Don, Saturday, October 11, 2008, 9:21:47 PM, you wrote: > It collects the 7 or so known issues that break code with GHC 6.10. i've quickly tried to compile my app with 6.10 (using base4). all the problems i got was due to exception handling. catch, finally, throwIO doesn't work added to wi

Re[2]: A wiki page for managing the 6.10 handover

Hello Don, Saturday, October 11, 2008, 9:54:10 PM, you wrote: seems that i misunderstood it: i thought it's a list of base4 vs base3 changes, but actually it seems like a base30 vs base31? base3 -> base4 upgrade hints are not documented anywhere? > bulat.ziganshin: >> Hello Don, >> >> Saturda

Re[2]: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Hello Thomas, Tuesday, October 14, 2008, 2:46:45 PM, you wrote: > The issue is binary compatibility. At the moment, GHC cannot make > sure that a library compiled with an older GHC can work with a newer > GHC. GHC does many cross-module optimisations, and its runtime system > changes occasional

Re: [Haskell-cafe] How to getCh on MS Windows command line?

흐壹o 鉅, 工賊嫂, 膠墮將奄 굅, 껐갭, 맏굡별9 죌, 闔u 破訂佯 > 羸受 I 張灑 戌 銳遷h 稶 淸e 全縡醇連奄抑 全縡憶寥抑 墮膣旭n 湞 銳遷矮枳 > 婆芋h 흽奧 出抑 剃 倧貞藕抑 修 灑 予輒塡旭n 醇t 全t 灑y 獐鎭. 괼 派姪s 烈r 張 彧 預屎 銳凸藕鴨狙矮r = 一厭M ⓦ嶢.說碇퇀蹴) 伸銳諜h 烈鎭遇n 勖卒蛭 娠刷l 軸愴蓮 ㏂禎旭.h 銳諜熬 伸銳諜h 볶 IO 촁塼 껍 暢踐祝蓮侄蹟工鴨 彩昻n 膠찢連奄彧g 全t 輒彩抑 낟 出e 彧輒賑辛. i 鴨鳶迹輒稔 鎭張將奄 淸受 i 矮d 臆蓮辛 闔u 赤抑 淸稶 投陂 倧

Re[2]: [Haskell-cafe] How to getCh on MS Windows command line?

Hello Ki, Tuesday, November 11, 2008, 4:04:11 AM, you wrote: i have also linux getCh if you need it, although afaik it's not perfect and actually you should use something inside Unix package -- Best regards, Bulatmailto:[EMAIL PROTECTED] __

Re[2]: Bug in GHC6.10.1?

Hello José, Friday, November 14, 2008, 5:32:52 PM, you wrote: > 0.6001 computers store floating-point numbers in binary form, and it's imposiible to represent 3/5 in binary form exactly for the same reasons as impossibility to represent 1/3 exactly in decimal form (sorry for awkward

Re: Unicode's greek lambda

Hello Kazu, Tuesday, November 18, 2008, 12:00:25 PM, you wrote: > characters including left/right arrows. Unfortunately, the letter > "greek lambda" cannot be used. Are there any technical reasons to not > accept it? i think it is accepted as usual letter - reason is that greeks can use it in th

  1   2   3   4   5   >