June 2002 - Libraries

How can I convert from type GUI String to String?
by Bruno de Andrade Felipe 16 Jun '02

16 Jun '02

I am building an interface using the tclhaskell and I need to get what the user types in the "entry" but the function "getEntry" returns a GUI String and the function "setEntry" needs a String not a GUI String. So how can I convert from GUI String to String?? Or is there any other way to get waht the user type? thanks for the help Here is the code: botao <- button janela [text "Muda Texto", command (setEntry entrada2 (getEntry entrada1))] __________________________________________________________________________ Quer ter seu próprio endereço na Internet? Garanta já o seu e ainda ganhe cinco e-mails personalizados. DomíniosBOL - http://dominios.bol.com.br

1 0

FiniteMap: modifyFM
by Jon Fairbairn 15 Jun '02

15 Jun '02

I'm using a FiniteMap with fairly long keys; I need to change the value associated with a key fairly often. The current definition of addToFM looks like this: addToFM fm key elt = addToFM_C (\ old new -> new) fm key elt addToFM_C combiner EmptyFM key elt = unitFM key elt addToFM_C combiner (Branch key elt size fm_l fm_r) new_key new_elt | new_key < key = mkBalBranch key elt (addToFM_C combiner fm_l new_key new_elt) fm_r | new_key > key = mkBalBranch key elt fm_l (addToFM_C combiner fm_r new_key new_elt) | otherwise = Branch new_key (combiner elt new_elt) size fm_l fm_r (Or at least I wish it did -- the #ifs and lines > 80 chars make it hard [for me at least] to read). Now, in the case where equality from Ord key is an equivalence rather than true equality, I can see that using "new_key" in the otherwise case is the right thing to do. For my case, it means that the recently allocated new_key replaces the old key that will have been around longer. Doesn't this interact badly with generational collectors? Oh yes, and since the similar operations on Refs and states are called modifyBlah, shouldn't the _C versions of operations on FiniteMaps be called something with "modify" in them? so addToFM_C would become modifyFM addListToFM_C ----"--- listModifyFM etc. I think names with words rather than abbreviations are easier to read when returning to something after a long period of absence. Jón -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk 31 Chalmers Road jf(a)cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)

1 0

RE: HTTP Implementation
by Simon Marlow 10 Jun '02

10 Jun '02

> Simon Marlow wrote: > > > > ... > > > > The HTTP module itself can go in Network.Protocols.HTTP, and Browser > > maybe in Network.Protocols.HTTP.Browser. Base64 is a little more > > generic - perhaps FileFormat.Base64? > > How about FileFormat.Encoding.Base64? > > In the future, > > FileFormat.Encoding.QuotedPrintable > FileFormat.Encoding.Gzipped > FileFormat.Encoding.Yenc > Text.Encoding.Rot13 Yes, I like that; except that for gzip we already have FileFormat.Compression.Gzip. Unless there are any objections, I propose we adopt FileFormat.Encoding and Text.Encoding. BTW, I just updated http://www.haskell.org/~simonmar/lib-hierachy.html with the latest version of the hierarchy. Cheers, Simon

3 2

RE: Unix Dir for .hi Import Files
by Simon Marlow 10 Jun '02

10 Jun '02

> > on somewhat of a tangent, i was running into problems with where > > both nhc and ghc place their hi files when attempting to compile > > from a read-only filesystem, the standard autoconf setup (as used in > > DrIFT http://repetae.net/~john/computer/haskell/DrIFT) works almost > > perfectly except the .hi files always seem to be placed in the same > > directory as teh source files rather than with the .o files as would > > seem to make sense. > > Thanks. This is a very clear statement of a similar problem I was > having when building a project with GHC. I don't recall all the > details now but I remember having to fight rather hard to get GHC to > place files in the right place and even harder to get GHC to generate > Make-style dependency files containing the correct directories. In > the end I think I settled on compromising the directory structure I > wanted and writing a perl script which munged the generated dependency > files. The fragility of this approach was demonstrated on the next > release when a slight change in the format of one of the GHC-generated > files threw my Makefile and script out of whack. > > Sorry I can't fill in details - this was about 18 months ago and the > only records I have are some ugly-looking Makefiles. The point of my > anecdote is just to add weight to the argument that this is an > important issue to get right. If there's a problem here I'd like to get it nailed. Take a look at the GHC documentation, in particular the section on flags for redirecting output: http://www.haskell.org/ghc/docs/latest/set/flag-reference.html#AEN4986 and let me know if there's anything that's not covered, or you think should be done differently. John's problem above sounds like it would be solved by using the -hidir flag. Cheers, Simon

1 0

Re: Unix Dir for .hi Import Files
by Malcolm Wallace 10 Jun '02

10 Jun '02

Ashley Yakeley <ashley(a)semantic.org> writes: > I'm not sure if there's any standardisation effort or intent for .hi > files, or whether they are likely to remain GHC-specific for the > forseeable future, Each Haskell compiler has its own .hi format. An idea has been floated that there should be a standard 'minimal' .hi format, but it is not clear that it would be useful in practice, since the extra stuff the compiler normally puts in there must be for a reason. > but I was wondering if there should be a standard > UNIX directory to put them in. For instance: > > /usr/share/haskell-import/Org/Org/Semantic/HBase/Basic/Trivial.hi > > ...much like C has "/usr/include/". This is very difficult, because not only does the .hi format vary between compilers, but even with GHC alone it is utterly dependent on the version of the compiler. Hence, GHC's .hi files must go in directories like /usr/local/lib/ghc-5.00.2/imports /usr/local/lib/ghc-5.02.3/imports etc. However, you can organise your own libraries as a 'package' if you like, and keep all the .hi files that belong with it together. The GHC documentation has more info on how to build a package. (Nhc98 has also adopted a simplified version of GHC' package mechanism, to appear in the next release.) Regards, Malcolm

3 2

Re: Unix Dir for .hi Import Files
by Ashley Yakeley 10 Jun '02

10 Jun '02

At 2002-06-08 04:29, Alastair Reid wrote: >I don't see what's wrong with putting them in the same directory as >the .o file. In fact, given that the .hi and .o file must match >exactly (i.e., be generasted from the same .hs file using the same >compiler version and same compiler flags), I see many things wrong >with putting them anywhere other than where the .o file is. So you don't think the .o files should be collected together into a library? -- Ashley Yakeley, Seattle WA

2 1

Unix Dir for .hi Import Files
by Ashley Yakeley 08 Jun '02

08 Jun '02

I'm not sure if there's any standardisation effort or intent for .hi files, or whether they are likely to remain GHC-specific for the forseeable future, but I was wondering if there should be a standard UNIX directory to put them in. For instance: /usr/share/haskell-import/Org/Org/Semantic/HBase/Basic/Trivial.hi ...much like C has "/usr/include/". -- Ashley Yakeley, Seattle WA

2 1

RE: HTTP Implementation
by Simon Marlow 07 Jun '02

07 Jun '02

> "Warrick Gray" <oinutter(a)hotmail.com> writes: > > > I've been tinkering with a client-side HTTP/1.1 > > implementation for Haskell. [..] In the interests of > > finding all bugs and giving something for nothing I've > > made the code available: > > > > http://homepages.paradise.net.nz/warrickg/haskell/http > > Thanks I think it is a nice library. > > > Significantly missing is any hint of SSL and request > > pipelining. Suggestions on improvements are welcome. > > I tried HTTP.hs and Base64.hs a little and they seem to work > well so far. > > I think your http library would make a useful addition to > the Haskell libraries, at least as a starting point for a > standard HTTP library. I've asked Warrick if he'd like to incorporate his HTTP client implementation into the hierarchical libraries, and maintain it. He's happy to do that. Does anyone have any objections or comments? The HTTP module itself can go in Network.Protocols.HTTP, and Browser maybe in Network.Protocols.HTTP.Browser. Base64 is a little more generic - perhaps FileFormat.Base64? Cheers, Simon

3 2

Module Hierarchy Question
by Ashley Yakeley 07 Jun '02

07 Jun '02

Is it wrong or discouraged to have both modules "A.B" and "A.B.C"? For instance, I want to create a number of modules: Org.Org.Semantic.HBase.Basic.Trivial Org.Org.Semantic.HBase.Basic.Logic Org.Org.Semantic.HBase.Basic.Equivalence Org.Org.Semantic.HBase.Basic.Type etc. ... and then have a single module that collects them all up: module Org.Org.Semantic.HBase.Basic ( module Org.Org.Semantic.HBase.Basic.Trivial, module Org.Org.Semantic.HBase.Basic.Logic, module Org.Org.Semantic.HBase.Basic.Equivalence, module Org.Org.Semantic.HBase.Basic.Type, etc. ) where { import Org.Org.Semantic.HBase.Basic.Trivial; import Org.Org.Semantic.HBase.Basic.Logic; import Org.Org.Semantic.HBase.Basic.Equivalence; import Org.Org.Semantic.HBase.Basic.Type; etc. } -- Ashley Yakeley, Seattle WA

2 1

Haskell HBLAS Library
by Hal Daume III 03 Jun '02

03 Jun '02

Hi All, I've just finished porting the BLAS linear algebra library to Haskell and am about to begin porting the LAPACK lin alg extensions. Currently the "package" looks very flat: HBlas.Types -- basic type HBlas.Convert -- basic conversion routines HBlas.Level1 -- BLAS level1 routines HBlas.Level2 -- BLAS level2 routines HBlas.Level3 -- BLAS level3 routines since I intend to share types between the HBlas system and the HLapack system, I intend to (shortly) make it something like: LinAlg.Types -- basic types LinAlg.Convert -- conversion LinAlg.HBlas.Level1 .Level2 .Level3 LinAlg.HLapack.and-so-on Before I do this, since changing module names is nontrivial, I was looking for some input whether this would be sufficient, or if I should make it Math.LinAlg... or something else. or Contrib.LinAlg or whatever. I don't mean to start a huge discussion; if there's a correct thing to do, and someone would tell me that, that's sufficient. Also, I'm looking for someone to help me out packaging it all up; I know very little about making makefiles, etc. The whole package is fairly complicated, since it requries BLAS to be installed, greencard to be run, the haskell to be compiled, and haddock to generate the documentation. Hopefully someone will volunteer. Finally, I've been trying to make myself document the library; you can find a somewhat recent version of the haddock docs at: http://www.isi.edu/~hdaume/HBlas but this will probably move shortly. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0