Re: Takusen build error
Alistair Bayley wrote: >> I get a strange error building Takusen (more precisely: the module >> Foreign/C/UTF8.hs) with ghc-6.8.3. It says >> >> [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, >> dist/build/Foreign/C/UTF8.o ) >> /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: >> >> /tmp/ghc18936_0/ghc18936_0.s:1257:0: >> Error: symbol `base_GHCziBase_Z0T_closure' is already defined >> >> I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. > > What happens when you say: > ghc -c Foreign/C/UTF8.hs > > I expect you get the same error. Yes. > If so, then this is one for ghc maintainers. Indeed, it seems so, as Ian Lynagh wrote: > Thanks for the report; I've filed a bug here: > http://hackage.haskell.org/trac/ghc/ticket/2409 > > As a workaround, removing the (redundant) uses of > () `seq` > in Foreign/C/UTF8.hs makes the build go through. Thanks, Ian, for the quick response and the work-around which works fine for me. Cheers Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Takusen build error
I get a strange error building Takusen (more precisely: the module Foreign/C/UTF8.hs) with ghc-6.8.3. It says aragon: .../ghc-6.8.3/Takusen-0.8.1 > ./Setup build -v Reading parameters from /srv/projects/ctl/franksen/haskell/ghc-6.8.3/Takusen-0.8.1/takusen.buildinfo Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library Takusen-0.8.1... Building Takusen-0.8.1... Building library... Creating dist/build (and its parents) Creating dist/build (and its parents) /projects/ctl/franksen/usr/bin/ghc -package-name Takusen-0.8.1 --make -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -I/opt/oracle/product/client/rdbms/demo -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package mtl-1.1.0.1 -package time-1.1.2.1 -package old-time-1.0.0.0 -O -XCPP Database.Enumerator Database.Util Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 Database.InternalEnumerator [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, dist/build/Foreign/C/UTF8.o ) /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: /tmp/ghc18936_0/ghc18936_0.s:1257:0: Error: symbol `base_GHCziBase_Z0T_closure' is already defined I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. Any ideas? Cheers Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.8.3 binary dist problem
Ian Lynagh wrote: > On Thu, Jun 26, 2008 at 02:51:05PM +0200, Benjamin Franksen wrote: >> aragon: .../i386-unknown-linux/ghc-6.8.3 > utils/pwd/pwd forwardslash >> [1]28489 floating point exception utils/pwd/pwd forwardslash > > This happens when your system (libc?) is too old to run the binaries in > the bindist. If you want to use newer versions of GHC on this system > then I'm afraid you'll have to compile them yourself. Thanks. Indeed, we are on debian stable, here. At home I have the latest kubuntu and there the binary dist works just fine. Cheers Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.8.3 binary dist problem
When I try to ./configure, I get this error: aragon: .../i386-unknown-linux/ghc-6.8.3 > ./configure --prefix=/projects/ctl/franksen/usr checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... configure: error: cannot determine current directory Looking into configure, I see that it calls 'utils/pwd/pwd forwardslash' which seems to be the culprit, since aragon: .../i386-unknown-linux/ghc-6.8.3 > utils/pwd/pwd forwardslash [1]28489 floating point exception utils/pwd/pwd forwardslash Cheers Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc command line evaluation
On Wednesday 05 April 2006 20:32, Pedro Miguel Duarte wrote: > I am writing a Java program with a call to a Haskell module M.hs, > in order to evaluate some expression expr. > > A very simple idea, which I got somewhere in the net, is to create a > Process object p which executes a GHC command-line instruction: > > Process p = Runtime.getRuntime(); > p.exec( " ghc M.hs -e \"expr\" " ); > > > This would be very simple, if it worked... > > > My problem is that expressions i want to evaluate involve > strings, and GHC command-line 'ghc' misinterprets some special > symbols when it parses double quoted strings. > > For instance, > ghc -e " reverse \"2<3\" " gives an error! Hmm. On my Linux machine (running zsh): [EMAIL PROTECTED]: .../play/ghc-e > ghc -e " reverse \"2<3\" " "3<2" But now I see that you run 'p.exec' in Java which probably translates (more or less) to a 'exec' system call. 'exec' is not a shell, it cannot translate complex quotings and unquotings. I would try p.exec( "/bin/sh ghc M.hs -e \"expr\" " ); or something similar. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Possible runtime overhead of wrapping the IO monad?
On Thursday 30 March 2006 14:13, Brian Hulley wrote: > John Meacham wrote: > > On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote: > >> where the intention is that the callback will take the width and > >> height of the window and return a RenderM action, the problem is > >> that because the FFI does not allow RenderM to appear in a foreign > >> type. > > > > it should, the types in foreign declarations should "see through" > > newtypes. > > Unfortunately GHC does not seem to support this: > >foreign import ccall duma_clear :: Word.Word32 -> RenderM () > >Unacceptable result type in foreign declaration: RenderM () >When checking declaration: >foreign import ccall safe "static &duma_clear" > duma_clear :: GHC.Word.Word32 -> RenderM () > > even though the FFI spec agrees with you (Section 3.2): > > The argument types ati produced by fatype must be > marshallable foreign types; that is, each ati is either (1) > a basic foreign type or (2) a type synonym or renamed > datatype of a marshallable foreign type. Moreover, the > result type rt produced by frtype must be a > marshallable foreign result type; that is, > it is either a marshallable foreign type, ... Note that the addendum continues "...that is, it is either a marshallable foreign type, the type (), or a type matching Prelude.IO t, where t is a marshallable foreign type or ()." Nowhere is it written that 'IO t' (in itself) is a marshallable type whenever 't' is a marshallable type. [I am not sure what it means exactly if a type "matches" 'Prelude.IO t'.] Thus, GHC does nothing wrong, according to the addendum. That doesn't mean allowing IO-equivalent newtypes wouldn't be a good idea. It is just not written in the addendum. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: --make keep going?
On Friday 03 March 2006 15:10, Bulat Ziganshin wrote: > it will also be great to make syntax analysis of all source files > before compiling them. typical situation - after correcting program i > run --make, long wait while some modules will be compiled and only > after that ghc complains about some error. it's not yet feature req, > just some thoughts about ideal compilation cycle: first syntax check > all modules and print errors, then perform type analysis and report > errors, then compile correct modules. what other haskellers think > about this? Sounds nice. But is it possible? I have no idea. > another problem is what ghc tries to print entire block when it > encounters error. but this block can contain hundreds of lines! > moreover, error message and line number printed at the beginning, so > on 25-line terminal it's just impossible to know anything about bug! > it will be great to print maximum one line, i think 25-line terminal and no scroll bar, how poor. I thought that everybody nowadays has access to screens with graphical resolutions, not? Anyway, this would be an nice option, but it should not be the default. What about compiler switch --terse? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: storing highly shared data structures
On Thursday 29 December 2005 18:22, Christian Maeder wrote: > Einar Karttunen wrote: > > On 22.12 14:43, Christian Maeder wrote: > >> How can I detect this sharing in order to avoid traversing the > >> very same symbol table for every symbol? > > > > By using System.Mem.StableName > > SerTH (http://cs.helsinki.fi/u/ekarttun/SerTH/) implements this, > > so you can look at the source for pointers. > > Thanks for your hints. What a pity that "makeStableName" goes to IO > (why would this break referential transparency?) and that "StableName > a" and "TypeRep" have no Ord instances. This has been asked before (by me too). The reason is that (due to efficient implementation issues) the order relation between TypeReps is not guaranteed to be the same for every program run. I guess the situation is similar with makeStableName, which is in the IO monad because the result may be different between program runs even given the same value as input. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: jhc vs ghc and the surprising result involving ghc generatedassembly.
On Thursday 27 October 2005 13:11, John Meacham wrote: > I am not sure how much sense this makes though. I am no expert on the > spineless tagless G machine (which would make an excellent name for > a band BTW) :-) Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Windows (DLL/FFI) woes
On Monday 24 October 2005 12:01, Simon Marlow wrote:
> On 23 October 2005 19:00, Esa Ilari Vuokko wrote:
> > I have been trying to build some Windows DLLs with
> > GHC, and I have run into some misfeatures or maybe
> > I have misunderstood how to use GHC. Any help or
> > advice would be appreciated. :)
> >
> > First of all, I can't get ghc to generate stubs from
> > foreign export in anywhere else than next to original
> > source, which is sort of annoying. I would like all
> > the generated files to go quite a bit diffrent place than
> > source directory.
>
> We don't have a flag for that; perhaps we should. Or perhaps there
> should be a flag that says "put all generated files here", that
> subsumes -odir, -hidir, -hcdir and also coveres _stub.{c,h} files.
Yes, please! This would have helped me a lot in a past project, where I
wanted to build two slightly different versions at the same time.
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to make Data.Set.Set a Functor
On Tuesday 11 October 2005 18:16, Lajos Nagy wrote: > While working on a toy compiler I realized that Data.Set.Set (Set) is > not an instance of the Functor class. In other words: 'fmap' is not > defined on it. I tried various ways of defining an instance but I > failed. The reason is quite interesting: Set is a type constructor > (* -> *) so it should qualify it for being a Functor. (In a sense it > is very similar to a Map or a list.) However, most Set functions > require the elements of the Set to be an instance of Ord. The > problem is that this constraint cannot be deduced from the instance > declaration for Functor: > > [...] > > On the other hand, it seems intuitively natural to make Set an > instance of fmap. Any ideas on how to do it? Hi, you are not the first one to observe this. AFAIK, there is no really satisfactory solution available. The general problem is discussed and a solution (a language extension) proposed in (http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps). Cheers, Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Inferred type is less polymorphic than expected?
On Monday 08 August 2005 09:43, Simon Peyton-Jones wrote:
| | > Are you saying, that the second error causes the first one? Thus,
| | > everything is caused by 'printer' being recursively defined?
| |
| | Yes, that's what I believe. I'm not sure why it shows the first
| | error message at all; in my experience, strange things happen when
| | ghc continues after an error message that you shouldn't pay too
| | much attention to. Perhaps ghc-6.4 just assumes identical contexts
| | in recursive groups without checking the type signatures.
|
| After an error in a function definition for f, GHC carries on
| assuming the function has type
|
| f :: forall a. a
|
| That very seldom leads to subsequent errors, but maybe it did this
| time. The way to find out is to show the program that elicits this
| message but not the other.
As Thomas correctly guessed, this happens if the type signatures of both
'printer' and 'printCatalog':
\begin{code}
class Catalog c where
traverse :: c -> Viewer -> IO ()
instance Catalog Int where
traverse i v = viewShowable v i
type View a = a -> IO ()
data Viewer = Viewer {
viewShowable :: forall s. Show s => View s,
viewCatalog :: forall c. Catalog c => View c
}
--printer :: Viewer
--printer = Viewer {
-- viewCatalog = \x -> traverse x printer,
-- viewShowable = putStrLn . show }
printer = Viewer {
viewCatalog = printCatalog,
viewShowable = putStrLn . show }
--printCatalog :: forall c. Catalog c => View c
printCatalog x = traverse x printer
data X = X {
cat :: Int
}
instance Catalog X where
traverse x v = do
viewCatalog v (cat x)
main = do
let x = X { cat = 20 }
traverse x printer
\end{code}
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Idempontent IO actions and unsafeSTMToIO
On Saturday 06 August 2005 20:12, Robert van Herk wrote: > Is it true to say that to perform idempotent IO actions inside a STM > monad by using unsafeSTMToIO is safe? I mean something like: > > do ... -- some STM actions > unsafeSTMToIO a -- Here, a is an idempotent IO action > ... -- some other STM actions > > What I read from the various sources on the web is that unsafeSTMToIO > is just unsafe in the sence that the IO actions may be performed > multiple times. So I recon that, if the IO actions are idempotent, > there would be no problem. > > Am I correct? I think that idempotent actions could still cause problems. For instance, assume the action is 'remove file x', which is surely idempotent. Now, imagine the following STM code: do doit <- readTVar v unsafeIOToSTM (do removeFile filename) if not doit then retry else return () Here, the file gets removed regardless of the value of the TVar 'v', although (presumably) it should be run only when 'v' contains 'True'. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Inferred type is less polymorphic than expected?
On Saturday 30 July 2005 03:54, Thomas Jäger wrote: > You're probably refering to the version where you omit the type > signatures of both 'printer' and 'printCatalog'. Here the situation > is different because the compiler needs to infer the types and not > just check. In the explicitely typed version, 'printCatalog' is used > polymorphically, i.e. the 'c' is instantiated to different types > during the recursive call. Thus the example needs polymorphic > recursion, for which type inference is known to be undecidable. It is > therefore reasonable that ghc (as well as hugs) can't compile the > code (in fact, I guess type inference will assume that both contexts > are equal). Hmm. I am not sure I understand this. Are you saying, that the second error causes the first one? Thus, everything is caused by 'printer' being recursively defined? Are contexts with differing length in a recursive definition ok in Hugs (as in the latest version of ghc) and therefore with Hugs I don't get the first message either? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Inferred type is less polymorphic than expected?
On Saturday 30 July 2005 01:46, Thomas Jäger wrote: > This is not a bug, the restriction is actually mentioned in the > Haskell Report, section 4.5.2. However, the restriction was recently > lifted, so your code compiles fine with the current cvs ghc, see > > > http://www.haskell.org/pipermail/glasgow-haskell-users/2005-July/00 > >8786.html > > Thomas > > On 7/29/05, Benjamin Franksen <[EMAIL PROTECTED]> wrote: > > Bug.lhs:27:0: > > Contexts differ in length > > When matching the contexts of the signatures for > > printer :: Viewer > > printCatalog :: forall c. (Catalog c) => View c > > The signature contexts in a mutually recursive group should all > > be identical Thank you for clarifying the cause of the second error message. Is there a connection to the first one? Note, I have a version of the program, where I only get the "Inferred type is less polymorphic than expected" error message and this one also disappears as soon as I use a lambda instead of a top-level function to initialize the record. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Inferred type is less polymorphic than expected?
Hi,
I get an error message when I compile the following program with
ghc-6.4:
\begin{code}
class Catalog c where
traverse :: c -> Viewer -> IO ()
instance Catalog Int where
traverse i v = viewShowable v i
type View a = a -> IO ()
data Viewer = Viewer {
viewShowable :: forall s. Show s => View s,
viewCatalog :: forall c. Catalog c => View c
}
printer :: Viewer
--printer = Viewer {
-- viewCatalog = \x -> traverse x printer,
-- viewShowable = putStrLn . show }
printer = Viewer {
viewCatalog = printCatalog,
viewShowable = putStrLn . show }
printCatalog :: forall c. Catalog c => View c
printCatalog x = traverse x printer
data X = X {
cat :: Int
}
instance Catalog X where
traverse x v = do
viewCatalog v (cat x)
main = do
let x = X { cat = 20 }
traverse x printer
\end{code}
This is a stripped-down version of my actual code, BTW. The exact mesage
is:
~> ghc -fallow-undecidable-instances -fglasgow-exts Bug.lhs
Bug.lhs:23:10:
Inferred type is less polymorphic than expected
Quantified type variable `c' is mentioned in the environment:
printCatalog :: c -> IO () (bound at Bug.lhs:28:0)
In the `viewCatalog' field of a record
In the record construction: Viewer
{viewCatalog = printCatalog,
viewShowable = putStrLn . show}
In the definition of `printer':
printer = Viewer {viewCatalog = printCatalog, viewShowable =
putStrLn . show}
Bug.lhs:27:0:
Contexts differ in length
When matching the contexts of the signatures for
printer :: Viewer
printCatalog :: forall c. (Catalog c) => View c
The signature contexts in a mutually recursive group should all be
identical
The code compiles and works fine if the definition of 'printer' is
replaced by the out-commented version, that is, if a lambda expression
is used that is identical to the definition of 'printCatalog'. BTW,
this does not happen with hugs.
It looks like a bug to me, but since I use some non-standard features,
maybe there is some subtle explanation for this behavior.
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linking shared libraries
I know that ghc cannot produce shared libraries on all systems, but what about just linking existing ones (i.e. for ffi code)? Is there a secret command line switch for that, or do I have to use the C linker? Is there an option in cabal that I have been missing that could help me? Cheers Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Cabal as shiped with ghc...
...has package version 1.0, but the current darcs repo (and the home page) says latest version is 0.6. May I assume that the 1.0 versioning is accidental (i.e. wrong)? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc for hp-ux 10.20 or 11
On Thursday 21 April 2005 11:38, Benjamin Franksen wrote: > Has anyone ever succeeded in porting ghc to HP-UX 10.20 or later? Sidenote: The background is that I want to persuade people at work to switch from CVS to darcs. It would be a lot easier to do so if I could get darcs to compile under (at least) HP-UX 11. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc for hp-ux 10.20 or 11
Has anyone ever succeeded in porting ghc to HP-UX 10.20 or later? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: simple question
On Saturday 02 April 2005 22:29, Peter Hercek wrote: > What is $ function good for? Mostly for avoiding parentheses. $ is right associative and has lowest precedence, whereas normal application is left associative and binds most tightly: f $ g $ h x === f ( g ( h x ) ) There are more advanced uses of $ but I'll let others elaborate on that. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
I haven't followed this thread too closely so please excuse me if this has already been mentioned (or even fixed). After I installed the latest binary package (20050228) the documentation was not correctly linked from the main documentation page. 'Hierarchical Libraries' on the main page points to /usr/local/share/ghc-6.4.20050228/html/libraries/index.html, but in this directory there is no index.html, only subdirectories. The link named 'Cabal' is also dead: file:/usr/local/share/ghc-6.4.20050228/html/Cabal/index.html does not exist). This is clearly non-critical, but it would be nice if it could be fixed in the final version. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Scrap your boilerplate (but don't scrap them precious comments)
Hi,
I have been racking my brain over the infamous 'gfoldl' and 'gunfold'
combinators. (Yes, I have read the papers). What finally made me understand
how they worked was reading the code: first the implementation of the gmap
functions (Data/Generics/Basics.hs), then the long and detailed comments in
the same file, and finally the instance definitions for the built-in types
(in Data/Generics/Instances.hs).
IMHO, a lot of this could and should be part of the (haddock-generated)
documentation.
It is such a waste: all these wonderful comments in the source file, that
could be added to the docs with a keystroke! Instead, they simply say
"Left-associative fold operation for constructor applications"
which is really a bit terse for gfoldl, of which the source file comment
(rightly) states that its type is a "headache".
Furthermore, (example) implementations can sometimes be extremely helpful to
understand things; this is especially true for a language like Haskell, in
which the implementation is often already the shortest (or at least a very
short) and most precise way to specify a functions semantics.
In this case, the implementations of gfoldl helped me to understand what the
function itself does. However, how and why these extremely abstract
combinators can serve as the basic building blocks of all the more concrete
and better understandable variants is best documented by the implementation
of just these variants gmapXX and friends. (Maybe one or two examples
implementations would suffice). At least, it should be stated in the docs
what the type constructor ('c') is in each case.
I don't know if haddock can add the implementation of a function to the
documentation. If not, such a feature should be considered.
SYB is a wonderful piece of work and deserves to be documented as well as it
is programmed.
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc -e
On Wednesday 24 November 2004 02:39, Nils Anders Danielsson wrote: > On Wed, 24 Nov 2004, Benjamin Franksen wrote: > > What about putting this thing on the Haskell Wiki? > > Feel free to do so. I recently noted that some version of GHC (6.3?) > ships with a runghc program, so this problem will most likely disappear > soon, though. > > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/utils/rung >hc/runghc.hs Nice to hear that. Publishing the code is obsolete then. Ben ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc -e
On Wednesday 17 November 2004 15:06, Nils Anders Danielsson wrote: > On Wed, 17 Nov 2004, Benjamin Franksen wrote: > > I want to use ghc as a script interpreter, using the '-e' option. The > > problem is that I can't give the script any command line arguments, > > because 'ghc -e' intepretes everything argument as the name of a module > > to compile. > > I once wrote a script which circumvented the issue above by using > System.Environment.withArgs. It works, but it is of course a little > clunky. > > See the attached sources. Thanks a lot! I needed to modify it a little to suit my preferences but it works like a charm. BTW, it seems as if ghc already ignores a first line starting with "#!", which makes the program a bit simpler. What about putting this thing on the Haskell Wiki? Cheers, Ben PS: Sorry for the delayed answer. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
On Tuesday 23 November 2004 13:06, Simon Marlow wrote: > On 22 November 2004 17:28, Benjamin Franksen wrote: > > I understand that there are situations where finalizers cannot be > > guaranteed to run: First because of an unconditional termination > > signal (SIGKILL), second because of circular dependencies resulting > > in a deadlock. > > > > I don't understand why it is necessary to "performGC" explicitly, in > > order to run finalizers at *normal* program termination and without a > > deadlock. > > It isn't necessary to performGC explicitly. However, you might be > seeing a secondary effect due to Handles being finalised at program > termination too - a common problem is writing a finaliser that tries to > output something on a Handle, where the Handle gets finalised first. I see. > The original finaliser will then deadlock (or in 6.2.2 it'll get a more > informative exception). > > This is because at program termination we just run all the outstanding > finalisers without regard to ordering. Ordering is too hard to > establish, and would at the least require a full GC before running each > finaliser. Autsch. That doesn't sound reasonable indeed. (Though I still have a hard time to believe that there exist no efficient solutions to this problem.) > > BTW, the sensible thing to do in this case would be to throw an > > exception whenever a deadlock condition is detected. (That is, if it > > can be detected.) > > Yes, GHC does cause exceptions to be raised on deadlock. > > > However, what I don't understand is why touchForeignPtr is not > > honored in my example program: Note that the output text lines from > > the finalizers appear *before* the last action in the program (which > > is a second getChar). The finalizers *are* called by the GC, and > > still the order is wrong. > > Note that the GC only starts the finaliser thread. The program can > still terminate before this thread has run to completion Maybe it can in general. In the example I posted it definitely doesn't. You get the output from the finalizers before the program terminates, which happens only after you hit enter for the second time. If this argument still doesn't convince you, please add the following lines at the end of main, and run again: putStrLn "Program still not terminated, please hit again!" getChar putStrLn "Program termination will now be initiated." This shouldn't change anything that has been output before ;-) Cheers, Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
On Monday 22 November 2004 18:55, Sven Panne wrote: > Abraham Egnor wrote: > > I've found that when writing an interface to a C library that requires > > resource management, it's much better to use the withX (see > > Control.Exception.bracket) style of function than to use finalizers - > > programs are much easier to reason about and debug. > > ... and have a much more deterministic behaviour regarding resource > consumption. This is a very important point which is often forgotten. Ok, the 'withX' pattern solves both of the problems I mentioned and in addition is more deterministic (and, using bracket, also exception safe). Maybe I should use it instead of finalizers. However, I wonder if it is general enough to be the only method exported from a library. I doubt it, otherwise there would be no 'openFile' and 'hClose' in System.IO but only a 'withFile'. Do you recommend supplying 'newX' and 'freeX' in addition to 'withX'? Or should I rather use 'newX' plus finalizers for those (rare?) cases where 'withX' is not general enough? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
On Monday 22 November 2004 14:45, Simon Marlow wrote: > On 20 November 2004 23:02, Benjamin Franksen wrote: > > I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr > > inside the finalizers to express liveness dependencies as hinted to > > by the documentation. This doesn't seem to work, though, or at least > > I can't see what I've done wrong. I attached a test module; compiled > > with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version > > 6.2.2, this gives > > > > .../foreigntouchbug > ./a.out > > > > before finalizing A > > after finalizing A > > before finalizing B > > after finalizing B > > > > > > I expected the order of the finalizer calls be be the other way > > around, since the finalizer for the Bs explicitly touches the A value. > > The problem is that the runtime is running all outstanding finalizers at > the end of execution, without regard for GC dependencies like the ones > introduced by touchForeignPtr. I understand that there are situations where finalizers cannot be guaranteed to run: First because of an unconditional termination signal (SIGKILL), second because of circular dependencies resulting in a deadlock. I don't understand why it is necessary to "performGC" explicitly, in order to run finalizers at *normal* program termination and without a deadlock. BTW, the sensible thing to do in this case would be to throw an exception whenever a deadlock condition is detected. (That is, if it can be detected.) However, what I don't understand is why touchForeignPtr is not honored in my example program: Note that the output text lines from the finalizers appear *before* the last action in the program (which is a second getChar). The finalizers *are* called by the GC, and still the order is wrong. > I've been planning to remove this automatic running of finalizers for > other reasons. However, then you will get absolutely no guarantee that > your finalizer will ever run at all (indeed, the property isn't always > true right now, but it is usually true). It is unclear to me what "usually" means, here. Wouldn't it be better to state the conditions under which they are called resp. aren't? Documenting the current state of affairs would be to say - Finalizers are *not* guaranteed to run (instead they "usually" are, whatever that means). - Calling touchForeignPtr does *not* guarantee that the targeted foreignPtr is not finalized before this call. This would make it obvious that finalizers are not a reliable tool (which they aren't, at the moment). > Let me share with you something that I've come to appreciate over the > last few years: > > Finalizers are almost always not the right thing. > > Finalizers look terribly attractive, but often lead to a huge can of > worms - best avoided if at all possible. I am ready to believe this, but I am nevertheless somewhat disturbed. I use finalizers to automatically reclaim resources from a foreign library. If I don't use them, these resources must be reclaimed explicitly. This is bad for two reasons: (1) The programmer has to remember to reclaim resources. (2) Handles for such resources become invalid after reclamation. If finalizers are not the right thing, what else is? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Another finalizer question
The library docs say *** newForeignPtr :: ... ...Note that there is no guarantee on how soon the finalizer is executed after the last reference was dropped; this depends on the details of the Haskell storage manager. The only guarantee is that the finalizer runs before the program terminates. *** As others have noted too, there is in fact *no* guarantee that finalizers are called. The only way I found to force calling of finalizers is explicitly calling System.Mem.performGC before the program exits. Is this a bug in the implementation of finalizers or is the documentation wrong or am I just stupid? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bug in touchForeignPtr?
Hi, I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the finalizers to express liveness dependencies as hinted to by the documentation. This doesn't seem to work, though, or at least I can't see what I've done wrong. I attached a test module; compiled with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version 6.2.2, this gives .../foreigntouchbug > ./a.out before finalizing A after finalizing A before finalizing B after finalizing B I expected the order of the finalizer calls be be the other way around, since the finalizer for the Bs explicitly touches the A value. Ben -- Top level things with identity are evil.-- Lennart Augustsson import Foreign hiding (newForeignPtr) import Foreign.Concurrent import System.Mem (performGC) type A = ForeignPtr Int type B = ForeignPtr Bool newA :: IO A newA = do (pa::Ptr Int) <- malloc newForeignPtr pa $ do putStrLn "before finalizing A" free pa putStrLn "after finalizing A" newB :: A -> IO B newB fpa = withForeignPtr fpa $ \pa -> do (pb::Ptr Bool) <- malloc newForeignPtr pb $ do putStrLn "before finalizing B" free pb putStrLn "after finalizing B" touchForeignPtr fpa main = do a <- newA b <- newB a getChar performGC getChar ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc -e
Hello,
I want to use ghc as a script interpreter, using the '-e' option. The
problem is that I can't give the script any command line arguments,
because 'ghc -e' intepretes everything argument as the name of a module
to compile.
> cat Test.hs
import System
main = getArgs >>= print
> ghc -e Main.main Test.hs
[]
> ghc -e Main.main Test.hs blabla
Can't find module `blabla'
(use -v to see a list of the files searched for)
:1:
Failed to load interface for `Main':
Bad interface file: Test.hi
Test.hi: openBinaryFile: does not exist (No such file or
directory)
:1: Variable not in scope: `Main.main'
Is there a way to tell ghc that what follows are arguments to teh
program ('main') and not to ghc itself?
Ben
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit parameter constraints not inferred
On Saturday 06 November 2004 17:57, you wrote: > Benjamin Franksen wrote: > > My question: Is this as it should be or is it a bug? > > The Monomorphism Restriction. Grumble... I almost suspected it. Only the context in which I got the error originally didn't _look_ as if MR would apply, and when I fumbled with the simple test program I just forgot about it. Sorry to have bothered you and thanks a lot for the answer. Your explanation of the MR is the best I've seen so far. Ben ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Implicit parameter constraints not inferred
To be fair, the ghc docs do not mention constraint inference for implicit parameters. OTOH they do not say that signatures must be given explicitly if I use implicit parameters. However, I always thought that this would be ok: > main = let ?b = True in use_b > --use_b :: (?g::Bool) => IO () > use_b = print ?b It isn't: ghc -fimplicit-params says Unbound implicit parameter (?b :: a) arising from use of implicit parameter `?b' at TestBug.hs:4 In the first argument of `print', namely `?b' In the definition of `use_b': use_b = print ?b It works if I uncomment the signature. I also tried > use_b = print (?b :: Bool) but to no avail. Using ghc-6.2.2, btw. My question: Is this as it should be or is it a bug? Ben ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: :kind feature request in ghci
On Saturday 27 March 2004 16:33, S. Alexander Jacobson wrote: > Alternatively, is there another way to > figure out how to create an instance of > a class like this? > > class MyClass a b where emptyVal::a b > > Here are one of the thing that don't work: > > type MyType a = [a] > instance MyClass (MyType a) a where emptyVal=[] > > And I have no idea why... Well, you've been told why. Anyway, why do you insist on using a two parameter type class? The more general class MyClass a where emptyVal::a would do exactly the same. To make type constructor B applied to type C an instance you just write instance MyClass (B C) where ... for instance instance MyClass [a] where emptyVal=[] If you enable overlapping instances you could even add instance MyClass [Int] where emptyVal=[0] The only difference to your 2-parameter class is that now you can declare instances for simple types like Integer too. Is that a problem? Ben ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
