- Glasgow-haskell-users

Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
by Christian Maeder 04 Jan '08

04 Jan '08

(Let's discuss this openly on glasgow-haskell-users) I'm not happy about this framework hick-hack either. I've only pushed it, because we needed a readline solution on macs. The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs. Nobody supplied a binary distribution so far, though. I only supplied the binary distributions that I (naively) made anyway. Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed) In any case we should strive to fix the frameworks issues _and_ add support for static linking of gmp, readline and possibly other libs (plus license issues). HTH Christian Thorkil Naur wrote: > Hello, > > Thanks everybody. However, I believe that using a modified readline library is > debatable, mainly because it adds the burden of keeping this library > up-to-date to the GHC maintenance process. Having a renamed library is one > thing and it does not seem that also modifying the contents of the library is > an improvement. For me to consider this idea, it should be the very last > solution, every other stone having been turned. And I certainly believe that > stones remain to be turned in this case. > > I would very much like to hear your comments to this. > > In addition, if you must replace this framework with another with different > contents, I would suggest the use of some versioning scheme. Otherwise is > seems that a lot of confusion could result. > > Thanks and best regards > Thorkil > > On Thursday 03 January 2008 16:18, Ian Lynagh wrote: >> Hi Christian, >> >> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: >>> Judah's framework (2342543 Bytes) >>> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip >>> >>> should replace (my old one) >>> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip >> Done! >> >> >> Thanks >> Ian >> >>

1 0

Re: Unrecognized -F flag
by Christian Maeder 04 Jan '08

04 Jan '08

Thanks, for your report. It was my fault. I should not have modified utils/hsc2hs/Main.hs as described in the following links. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583 http://hackage.haskell.org/trac/ghc/ticket/1395 A fix is to replace your file <prefix>/lib/ghc-6.8.2/hsc2hs-bin with a new one that you can download from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… (635468 Bytes) a ppc version from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… (800044 Bytes) <prefix> above is /usr/local (or the one you've configured with) Does someone have a cute command to easily update this file in a binary distribution (without unpacking and repacking), so that Ian can replaced my binary-dists (replacing hsc2hs-bin manually is a bit of a pain). Christian Adam Smyczek wrote: > Hi Christian, > > I'm using your OS X (Tiger) Intel ghc-6.8.2 distribution downloaded from > haskell.org. > So far everything worked great until I run into one problem compiling > zlib 0.4.0.1. > Running build command I get the following error: > > Preprocessing library zlib-0.4.0.1... > ghc-6.8.2: unrecognised flags: -F/Users/asmyczek/Library/Frameworks > Usage: For basic information, try the `--help' option. > compiling dist/build/Codec/Compression/Zlib/Stream_hsc_make.c failed > command was: /opt/local/bin/ghc -c -package base-3.0.1.0 -package > bytestring-0.9.0.1 -F/Users/asmyczek/Library/Frameworks > dist/build/Codec/Compression/Zlib/Stream_hsc_make.c -o > dist/build/Codec/Compression/Zlib/Stream_hsc_make.o > > I'm newbie to Haskell, Cabal etc. and not sure what the root cause of > this problem is. > Google did not find any concrete solution as well. Do you have an idea > what the problem > could be or maybe some hints where I can start to dig into? > > Thanks, > Adam > >

1 0

[Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2]
by Christian Maeder 04 Jan '08

04 Jan '08

Hi, can someone explain the linking error below? (on Intel-Mac (Tiger?)) Preprocessing library HDBC-sqlite3-1.1.3.0... Building HDBC-sqlite3-1.1.3.0... [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) [2 of 7] Compiling Database.HDBC.Sqlite3.Types ( Database/HDBC/Sqlite3/ Types.hs, dist/build/Database/HDBC/Sqlite3/Types.o ) [3 of 7] Compiling Database.HDBC.Sqlite3.Utils ( dist/build/Database/ HDBC/Sqlite3/Utils.hs, dist/build/Database/HDBC/Sqlite3/Utils.o ) [4 of 7] Compiling Database.HDBC.Sqlite3.Statement ( dist/build/ Database/HDBC/Sqlite3/Statement.hs, dist/build/Database/HDBC/Sqlite3/ Statement.o ) [5 of 7] Compiling Database.HDBC.Sqlite3.ConnectionImpl ( Database/ HDBC/Sqlite3/ConnectionImpl.hs, dist/build/Database/HDBC/Sqlite3/ ConnectionImpl.o ) [6 of 7] Compiling Database.HDBC.Sqlite3.Connection ( Database/HDBC/ Sqlite3/Connection.hs, dist/build/Database/HDBC/Sqlite3/Connection.o ) [7 of 7] Compiling Database.HDBC.Sqlite3 ( Database/HDBC/Sqlite3.hs, dist/build/Database/HDBC/Sqlite3.o ) ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in dist/build/Database/HDBC/Sqlite3/Types.o ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in dist/build/Database/HDBC/Sqlite3/Types.o

2 2

<.> defined in GHC and System.FilePath
by Neil Mitchell 03 Jan '08

03 Jan '08

Hi The GHC API uses the <.> operator, which clashes with System.FilePath. Possibly this might want renaming to something else - I have absolutely no idea what it does! Prelude> :m GHC Prelude GHC> :i <.> (<.>) :: HsWrapper -> HsWrapper -> HsWrapper -- Defined in HsBinds Thanks Neil

3 3

Readline for Windows in the FAQ
by Walt Rorie-Baety 03 Jan '08

03 Jan '08

Maybe I'm just too new at this, but the GCH FAQ entry for readline in GHCi is confusing for me. Especially since it ends with the sentence "Instructions for GHC 6.2.2. are here." However, as the quote goes, "there's no 'here' here." - the location of the instructions are missing. Could someone please clue me in to what I'm missing? That way, I could edit the Wiki page, to clue in others better. -- This signature intentionally left blank

2 1

--make should not touch the -o file if it doesn't change it
by Alex Jacobson 02 Jan '08

02 Jan '08

Right now, if you recompile with --make, the exeutable gets a new timestamp. That seems incorrect. Is this a bug? -Alex-

2 2

Re: [Haskell] garbage collection of Concurrent Haskell threads?
by Simon Marlow 02 Jan '08

02 Jan '08

[ moving to glasgow-haskell-users(a)haskell.org ] Conal Elliott wrote: > Thanks, Simon. If I understand the mechanism you're describing, it > discards readers of an empty MVar when there are no other references to > the MVar *because* the MVar can never get written. And if there are > other readers but no writers, then I'm guessing GC wouldn't know that, > and none of the readers get discarded. Is that so? I'm not sure I understand precisely what you mean here. Do you mean when there are other running threads that might read the MVar in the future? In that case, yes, blocked readers would not be detected and sent an exception. > I think Baker & Hewitt's trick was analogous to discarding writers of an > already full MVar when there are readers (readMVar) but no takers > (takeMVar). (Though not quite, since readMVar is implemented via > takeMVar & putMVar.) It shouldn't be the case that you have a thread doing putMVar on a full MVar simultaneously with another thread doing readMVar, because the readMVar could be preempted between the take and put and then block - this would almost certainly be an undesirable race condition. > I guess that effectively means IVars instead of MVars. > > In either direction (blocked reader or blocked writer), the interface of > MVars (or IVars) would seem to prevent an accurate analysis, since GC > wouldn't know whether a Var reference was for reading or writing. > > Right? A simple solution might be to hide the Var itself and instead > expose reader and writer halves. If there's an analysis problem at all, > does that solution make sense? Absolutely. It ought to be possible to implement this using weak pointers in GHC, because you want relationships like "if a writer is alive, then the readers are alive", and this is the kind of thing you can express with weak pointers. Cheers, Simon > > Cheers, - Conal > > On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <simonpj(a)microsoft.com > <mailto:simonpj@microsoft.com>> wrote: > > GHC already garbage-collects threads that are blocked on an MVar > that is otherwise inaccessible (and hence cannot be updated). More > precisely, GHC sends the thread an asynchronous exception > (ThreadBlocked or something), so that it has a chance to clean up. > > > > So perhaps the GC you want is already implemented? > > Simon > > > > *From:* haskell-bounces(a)haskell.org > <mailto:haskell-bounces@haskell.org> > [mailto:haskell-bounces@haskell.org > <mailto:haskell-bounces@haskell.org>] *On Behalf Of *Conal Elliott > *Sent:* 24 December 2007 00:15 > *To:* haskell(a)haskell.org <mailto:haskell@haskell.org> > *Subject:* [Haskell] garbage collection of Concurrent Haskell threads? > > > > The classic paper "The Incremental Garbage Collection of Processes" > (http://citeseer.ist.psu.edu/baker77incremental.html) describes > "futures" and how particularly garbage collecting them when their > pending result is no longer referenced. I've been playing with an > implementation of futures in Concurrent Haskell ( > http://haskell.org/haskellwiki/Reactive) using MVars, and I'm > stumped about how to GC non-winning threads in a race between > futures ("parallel or"). I'm having winner kill loser, which seems > to work fine, though is potentially dangerous w.r.t locked > resources. Still, the elegance of a GC-based solution appeals to > me. Has anyone explored process GC ideas for Concurrent Haskell (or > STM)? > > Futures are implemented using Concurrent Haskell's MVars. I first > tried using STM and TVars, simply using orElse to implement mappend > for futures. However, I didn't see how to avoid nesting > "atomically", which yielded a run-time error. If anyone has ideas > about using STM & TVars for futures, I'd love to hear. > > Thanks, - Conal > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Haskell-cafe] Re: #haskell works
by Bulat Ziganshin 02 Jan '08

02 Jan '08

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 hope that win-x64 will be supported at least in this way noone asked my question about plans of win-x64 support. it's important for my users, so i ask you again - can you please implement it? to other GHC users: i'm pretty sure that win-x64 support will not be implemented if it's required only for me. so, if someone need it - please write about this to ghc debelopers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

ANNOUNCE: GHC version 6.8.2
by Ian Lynagh 02 Jan '08

02 Jan '08

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

17 66

laura.daun@web.am
by Daniil Elovkov 01 Jan '08

01 Jan '08

Привет Лаура! С Новым Годом тебя и всю твою семью! Мама говорит тебе там мало солнца. День начал удлиняться. Пусть тебе будет светло и тепло. Мы тебе желаем здоровья, интересных приятных событий, поездок, дел. Пусть Оке и дети будут здоровы, удчачливы, всем довольны и тебя радуют! Gott nytt år till dig, Åke, Aram och David (och deras flickor också) ! Даня и Даша.

1 1