Re: [Haskell] Re: state of HaXml?
On 1/10/07, Malcolm Wallace <[EMAIL PROTECTED]> wrote: "Samuel Bronson" <[EMAIL PROTECTED]> wrote: > > Can I just leave it hanging and rely on the garbage collector to > > close it in the fullness of time? > > Actually, hGetContents closes the handle when it gets an EOF. > > If it never does get EOF (because you never use all of the data), the > garbage collector *might* close the handle, but I haven't heard of a > garbage collector that was aware of the value of resources other than RAM Actually, I'm pretty sure that most Haskell RTS implementations have a finalizer attached to all file handles. Once the file handle is no longer reachable from the program graph (even if its data has not been fully consumed), the GC will close the file (via the finalizer) before reaping the memory associated with the handle. Yeah, what I mean is that the garbage collector does not *look* for unreachable filehandles to close, or get run when many filehandles have been allocated. It only runs finalizers when it happens upon things with finalizers, it doesn't have any idea what they are for. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: state of HaXml?
On 1/4/07, Norman Ramsey <[EMAIL PROTECTED]> wrote: > There seems to be a misunderstanding here: readFile in itself is not the > solution. readFile is defined thus: > > readFile name= openFile name ReadMode >>= hGetContents > > and the original code was this: > >load fn = do handle <- IO.openFile fn IO.ReadMode > contents <- IO.hGetContents handle > IO.hClose handle > return $ XP.xmlParse fn contents > > Sure, you can replace the openFile/hGetContents pair by readFile, but the > real problem is the presence of the hClose. Removing that will solve your > problem (but note that you now have no control over when the file is > actually closed). Can I just leave it hanging and rely on the garbage collector to close it in the fullness of time? Actually, hGetContents closes the handle when it gets an EOF. If it never does get EOF (because you never use all of the data), the garbage collector *might* close the handle, but I haven't heard of a garbage collector that was aware of the value of resources other than RAM (that is, they don't go out of their way to run finalizers and free up handles to OS resources). Java has the same problem, though I'm not sure if its file handles *have* finalizers, and Python does too, except the refcounting in CPython right now hides it. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] How to make sure that a function is evaluated only once?
On 12/21/06, Axel Jantsch <[EMAIL PROTECTED]> wrote: I have a function with type f :: Int -> Int -> Int -> Int -> Int -> NRup -> NRdown and I want to make sure it is evaluated only once for the same set of arguments but I observe that it is always evaluated several times. Maybe you want to memoize it? Memoization is when you wrap a function so that its results are stored in a data structure indexed by argument. This can be done either purely or impurely. What kind of argument ranges are we talking about? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: dlist, difference lists supporting O(1) append
On 12/10/06, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: This is DList, 0.1 I've cabalised, and packed up a small difference lists module. In case you've not used them, they are a Haskell idiom for implementing O(1) append and snoc, using functions to represent lists. Are they in Monoid? They should be! ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: ZMachine 0.0
On 12/9/06, Neil Mitchell <[EMAIL PROTECTED]> wrote: Hi Samuel, For future releases can you put up a little description of what a Z Machine is in the email? Hmm. That would probably be a good idea ;-). But I don't see why I can't do that now, too. Except I actually want to describe the Z-machine, because apparantly the Z machine is a big giant machine covered in what looks like lightning. Anyway, here is the description from Wikipedia: The Z-machine is a virtual machine that was developed by Joel Berez and Marc Blank in 1979 and used by Infocom for its text adventure games. Infocom compiled game code to files containing Z-machine instructions (called story files, or Z-code files), and could therefore port all its text adventures to a new platform simply by writing a Z-machine implementation for that platform. With the large number of incompatible home computer systems in use at the time, this was an important advantage over using native code (or developing some compiler for each system). And I'll also note that, since then, a lot of people have used Graham Nelson's Inform compiler to write their own "text adventure games" (or "interactive fiction", as they like to call it) for the Z-machine, many of which are available at the IF archive (ifarchive.org). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: ZMachine 0.0
I've written a (partial) Z-machine interpreter in Haskell. It is missing lots of stuff, but I got it to the point where it doesn't cause actual pain to play with it ;-). It uses gtk2hs for the interface, though other interfaces could be implemented without actually changing the interpreter proper. (Though I suppose you'd want to get rid of all the trace output if you were going to write a curses UI.) You can either darcs get http://naesten.dyndns.org:8080/repos/ZMachine or grab a tarball at http://naesten.dyndns.org:8080/repos/ZMachine/ZMachine-0.0.tar.gz Patches and comments are greatly desired. (Except for "where is the status area". At least I don't have the stuff intended for the status area going to the main output area like it used to!) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 30/05/05, Isaac Jones <[EMAIL PROTECTED]> wrote: > Samuel Bronson <[EMAIL PROTECTED]> writes: > > (snip) > > I think we might actually be suffering from the "invented here" > > syndrome, namely because we got early exposure to darcs and many of us > > got hooked. > > I kinda disagree here. Haskell people were not using sourceforge way > before we had Darcs :) (snip) Huh, you have a point there. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] fptools tree bsd3 licensed? was Re: PPrint license
On 30/05/05, Shae Matijs Erisson <[EMAIL PROTECTED]> wrote: > Samuel Bronson <[EMAIL PROTECTED]> writes: > > > Anybody know anything about this? > > I think anything in fptools is BSD3 licensed, but I'm not sure if that's true. I didn't know that was in fptools. I'll have to check that out again sometime. -- Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] PPrint license
I was messing around with some pretty printing stuff in Pugs, and I got tired of Text.PrettyPrint.HughesPJ, and wound up wanting to use PPrint. But I don't see any license anywhere for it, so I'm naturally a bit hessitant to stick it in the Pugs svn tree... Anybody know anything about this? -- thanks, Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: lambdabot 3.0
On 26/05/05, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: > lambdabot was written by Andrew Bromage, and is now a community > project. lambdabot 3.0 would not have been possible without the help of > the #haskell irc community -- this release features more than 450 > patches from 14 contributors. Lets not forget to mention David Roundy and his excellent darcs, which made it so easy to participate in development even when you were asleep. I don't think it would have been possible without that either. -- Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 26/05/05, Sven Panne <[EMAIL PROTECTED]> wrote: > Samuel Bronson wrote: > > The thing is, Haskell people tend to want to use Darcs for their > > Haskell stuff, and I don't think there are sites like sourceforge > > supporting it yet... > > So my question is (probably once again): Why can >100.000 projects > live with SF and not the Haskell community? Although CVS is not my > favourite version control system, I'd happily use it if I get the > rest of SF for free then. > > I have the very strong feeling that we are experiencing a "not > invented here" + "we can do it better" scenario... :-[ I see the > need for Cabal/Hackage, but I am far from being convinced that > building a SF-like site from scratch is the right way to go. Either > collaborating with the SF people or modifying GForge looks more > promising and economical to me. I think we might actually be suffering from the "invented here" syndrome, namely because we got early exposure to darcs and many of us got hooked. Just about every project I do goes into darcs pretty quick. I should make a script to make a directory and set up two repos named "base" and "work" under it, or maybe just set up one to copy around ;-). I'm sure most of us have used CVS and/or SVN with existing projects (or before darcs, or for things which need to run everywhere and not just where GHC runs), and some of us probably don't like darcs, but that doesn't mean others of us don't feel the need for darcs hosting. -- thought-I-had-sent-this-already-ly yrs, Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 26/05/05, Brian Smith <[EMAIL PROTECTED]> wrote: > On 5/25/05, Samuel Bronson <[EMAIL PROTECTED]> wrote: > > The thing is, Haskell people tend to want to use Darcs for their > > Haskell stuff, and I don't think there are sites like sourceforge > > supporting it yet... > > I tried to address this in my original email. There are several > hosting sites like Sourceforge around. Although it is unlikely that > SF.NET can be pursuaded to integrate Darcs (Subversion support has > been "investigated" for two years, I think), I bet an alternative site > could be pursuaded to install Darcs support. If so, this would benefit > all projects, not just Haskell-related ones. That could be nice, if especially if they could set it up so that it was easy to set up submit-by-mail something like the Darcs repo has, with a list of GPG keys to auto-apply patches from. > Also, if a new site had to be created specifically to provide Darcs > hosting, then why limit it to Haskell projects? I was actually thinking this too. It really would be annoying to have Darcs hosting only for Haskell projects. So I guess I really would prefer that it be one of the existing SF alternatives. -- Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
Whoops, I sent this to just brian by mistake. On 21/05/05, Brian Smith <[EMAIL PROTECTED]> wrote: > On 5/13/05, Gour <[EMAIL PROTECTED]> wrote: > > So, why not form HaskellForge and thereby form powerful Haskell > > alliance, ie. common site which can host many/most present Haskell > > projects offering appropriate web & other (eg. darcs) services? > > > > If we take a look on new HCAR, we can see that many Haskell projects are > > scattered all around, so it would be nice to have them on one place. > > On the other hand, I bet that the majority of developers here also > develop software using languages other than Haskell. Further, if these > people are like me, then I would want to keep all of my projects in > the same place, regardless of implementation language. That is, I > don't think that people would want to host their Haskell projects at > HaskellForge, Java projects at Java.net, Ruby projects at RubyForge, > etc. I think that these language-specific sites are best reserved for > infrastructure projects like compilers and reusable libraries. The thing is, Haskell people tend to want to use Darcs for their Haskell stuff, and I don't think there are sites like sourceforge supporting it yet... ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] RE: Should inet_ntoa Be Pure?
> http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.So > cket.html#v%3Ainet_addr > > > http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.So > cket.html#v%3Ainet_ntoa What is with this wrapping? Sorry to cross-post this, but I couldn't figure out what to cut out... ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Relative Module Imports
On 5/9/05, Simon Marlow <[EMAIL PROTECTED]> wrote: > On 06 May 2005 18:33, Samuel Bronson wrote: > > > On 5/6/05, Simon Marlow <[EMAIL PROTECTED]> wrote: > >> (d) I hoped that something like grafting would provide a more > >> general solution. > > > > Grafting sounds like a very nice solution just from the name, but I > > don't recall hearing of it before. Where can I read about it? > > The thread started here: > > http://www.haskell.org/pipermail/libraries/2003-August/001310.html For those who like gmane: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/672 -- Sam /me considers switching gmail's interface to UK English in the hopes that it will then give decently formatted dates. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Proposal: Relative Module Imports
On 5/5/05, S. Alexander Jacobson <[EMAIL PROTECTED]> wrote: > > On Tue, 3 May 2005, Samuel Bronson wrote: > > Maybe something like > > > > from Text.HaXML.XML import (Types, Escape, Pretty) > > > > would be nice. > > The problem with this one is that you need a way to express all the > other stuff in import statements like "qualified" or "as", the > imported list, etc. Hmm, I guess it isn't dead obvious what they would do, but it seems like it would make more sense that way than with braces-and-commas in the shell style. > If you don't like the dots and are willing to deal with having to type > the current module hierarchy twice, a more verbose syntax would be > >Proposal Translation >--- >module Foo.Bar.Baz.Bing where module Foo.Bar.Baz.Bing where >from Foo.Bar.Baz > import Blip import Foo.Bar.Baz.Blip as Blip >from Text.HaXML.XML > import Types import Text.HaXML.XML.Types as Types > import Escapeimport Text.HaXML.XML.Escape as Escape > > Not as tight as the prior syntax I proposed, but more readable and > still a large improvement on the status quo. > > Thoughts? That looks pretty much like what I had only with an import for each module, instead of one import with syntax a bit like deriving... probably much easier to parse, and a bit more obvious what it means. Definately makes qualified and friends more fine-grained than I was thinking. You could even nest them. Also, it is much easier on the eyes than your previous suggestion, and there are no dots to count. I like it ;-). --Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Relative Module Imports
On 5/6/05, Simon Marlow <[EMAIL PROTECTED]> wrote: > (d) I hoped that something like grafting would provide a more > general solution. Grafting sounds like a very nice solution just from the name, but I don't recall hearing of it before. Where can I read about it? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Proposal: Relative Module Imports
On 5/3/05, S. Alexander Jacobson alexjacobson.com> wrote:
> Problem: We need a way to simplify module imports.
>
> Problem details:
>
> * Hierarchical module names are getting really long (including a
> functional area, a package name, and a module name).
>
> * People typically import multiple modules from areas close to each
> other in the hierarchical module namespace (especially in the case of
> intra-package imports).
>
> * Long module names are required even for non-exposed modules because
> a program may contain only one module with a given name (regardless of
> its visibility).
>
> Idea: Allow module relative imports in a manner that does not break
> any existing code.
This would be really nice, but I'm not sure I like the way you propose
to do it. Those bare dots don't look very nice to me, and I really
don't like the idea of having to count them... I'm not even sure I
like the idea of imports relative to the current module.
I almost want "import Text.HaXML.XML.{Types,Escape,Pretty}", but not
quite. And that would not be nice for qualified imports, anyway.
Maybe something like
from Text.HaXML.XML import (Types, Escape, Pretty)
would be nice.
-- Sam
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
