[Haskell-cafe] Is ListT a valid MonadPlus?
It appears to me that the MonadPlus instance for ListT breaks the following MonadPlus law m >> mzero = mzero I've tried with every implementation of ListT I could find - the one in mtl, transformers, List, even "ListT done right" and it's alternative. They all seem to violate the above law. Following is a ghci session that shows this with the mtl impl. Prelude> import Control.Monad.List Prelude Control.Monad.List> let nt = ListT Nothing :: ListT Maybe Int Prelude Control.Monad.List> let e = mzero :: ListT Maybe Int Prelude Control.Monad.List> runListT nt Nothing Prelude Control.Monad.List> runListT e Just [] Prelude Control.Monad.List> runListT $ nt >> e Nothing According to the MonadPlus law above, that last line should evaluate to `Just []`. So is ListT a valid MonadPlus? Or am I missing something? If not, can a valid MonadPlus instance for ListT be written? I've tried a few things and come up short. Thanks, Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yesod and dependencies hell
Are you talking about starting a new site, or running an existing site? For a new site, it's probably a good idea to wait until 0.10 comes out, as it includes a lot of nice enhancements, and we'll be releasing it this week. If an existing site, you probably need to have more strict upper bounds on your package dependencies. Without seeing your cabal file, I can't really comment further. It also might be a good idea to move this discussion to the Yesod mailing list (CCed). On Wed, Feb 8, 2012 at 5:09 PM, Никита Тимофеев wrote: > For three days I can't compile dependencies for my project using > yesod, yesod-auth, yesod-persistent, persistent-template, > persistent-sqlite, persistent. When I varied version I received a > variety of broken dependencies: persistent (0.6.* vs 0.7.*), conduit > (0.1.* vs 0.2.*), conduit-pool, path-pieces, attoparsec and something > else. In this regard, I have a few questions. How to build these > packages together? And, Michael, why so bad? > > -- > Тимофеев Н.Д. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 214
Welcome to issue 214 the HWN, a newsletter covering stories, questions, and remarks seen around the web during the week of January 29 to February 4, 2012. You can find the HTML version at: http://contemplatecode.blogspot.com/2012/02/haskell-weekly-news-issue-214.html Quotes of the Week * Jafet: [on memoising an O(n) algorithm:] This is like trying to save work in a police investigation by having each detective determine whether another detective has already removed all evidence from his area by walking through it to search for evidence in the area. * CodeWeaver: keep in mind encryption's only as good as how much you trust that the implementors got it right. * cmccann: length [1..10^20] lambdabot: mueval-core: Time limit exceeded cmccann: looks like 10^20 is infinity * elliott: race condition waiting to happen * elliott: o'reilly publishes attoparsec tutorial: exactly the same as their parsec tutorial, but 10^-18th the size * rwbarton: Num works for Float/Double, it's Float/Double that doesn't work for Num * ddarius: Space isn't that big. * Brent Yorgey: > Sometimes, I suspect that Haskell not only makes easier of the hard > things for imperative programming languages but also makes harder of > some easy things. This is true. But usually these are things that you don't *want* to be easy, like shooting yourself in the kidney. (But these features are often described in ways that make them sound great, like "flexible usage of bullet-placement tools".) Inserting arbitrary print statements into the middle of some code is difficult for a reason. Top Reddit Stories * GHC 7.4.1 is out. Here's the release notes Domain: haskell.org, Score: 107, Comments: 59 On Reddit: [1] http://goo.gl/su4jl Original: [2] http://goo.gl/Nstve * Coming soon, to a bookstore near you Domain: yesodweb.com, Score: 82, Comments: 16 On Reddit: [3] http://goo.gl/6gZXg Original: [4] http://goo.gl/zSW1l * ImplicitCAD is a Programmatic CAD Tool/3D Modelling Engine in Haskell. Also my first big Haskell project. Feedback, advice? Domain: github.com, Score: 63, Comments: 23 On Reddit: [5] http://goo.gl/YHMRa Original: [6] http://goo.gl/39rc3 * Using monadic effects to reverse a merge sort Domain: github.com, Score: 42, Comments: 4 On Reddit: [7] http://goo.gl/dVuyp Original: [8] http://goo.gl/jL9qj * Exciting changes coming to conduit 0.2 Domain: yesodweb.com, Score: 38, Comments: 7 On Reddit: [9] http://goo.gl/neyW2 Original: [10] http://goo.gl/1ikN5 * Vectorisation without Replication in Data Parallel Haskell Domain: disciple-devel.blogspot.com, Score: 35, Comments: 4 On Reddit: [11] http://goo.gl/iJ4OD Original: [12] http://goo.gl/uMp4S * If software purity in functional languages is such an awesome idea, why are we still writing Python, Ruby or Java? Domain: self.haskell, Score: 33, Comments: 136 On Reddit: [13] http://goo.gl/F0QCY Original: [14] http://goo.gl/F0QCY * Released Data.Array.Accelerate 0.9.0.0 — the Haskell array library for GPUs Domain: justtesting.org, Score: 32, Comments: 3 On Reddit: [15] http://goo.gl/NqUwp Original: [16] http://goo.gl/JYTQ4 * Fun With -XPolyKinds : Polykinded Folds Domain: typesandotherdistractions.com, Score: 24, Comments: 1 On Reddit: [17] http://goo.gl/daxL8 Original: [18] http://goo.gl/u9gHi * Introduction to using acid-state, IxSet and data-lens as a native Haskell, noSQL, RAM-cloud database Domain: happstack.com, Score: 23, Comments: 21 On Reddit: [19] http://goo.gl/9bliO Original: [20] http://goo.gl/ZGXyW * Can't wait for the Haskell Platform? -- Compiling GHC 7.4.1 from source has never been easier. Domain: blog.jasonknight.us, Score: 21, Comments: 8 On Reddit: [21] http://goo.gl/IKjm6 Original: [22] http://goo.gl/dgMF2 * Generating random functions Domain: mainisusuallyafunction.blogspot.com, Score: 20, Comments: 6 On Reddit: [23] http://goo.gl/DB4f6 Original: [24] http://goo.gl/aOAPo * How to deal with undesired values when designing types Domain: self.haskell, Score: 19, Comments: 28 On Reddit: [25] http://goo.gl/aPCbQ Original: [26] http://goo.gl/aPCbQ * Guarded Pipes or How to write Conduit.List Combinators in Pipes. Domain: pcapriotti.wordpress.com, Score: 17, Comments: 16 On Reddit: [27] http://goo.gl/vo8ip Original: [28] http://goo.gl/mhnfH * UHC JavaScript Backend Project Page (Work in Progress) Domain: uu-computerscience.github.com, Score: 16, Comments: 0 On Reddit: [29] http://goo.gl/42xXs Original: [30] http://goo.gl/Cz8R6 Top StackOverflow Questions * What are the rules about concurrently accessing a persistent database votes: 17, answers: 1
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
> > I chose the most available non-ASCII character I could > find. Set the criterion to be "present in most ISO 8-bit > character sets" and there are really only two candidates, > section sign and degrees sign. ... > Brilliant! We'll use degrees sign for function composition (so that it follows the convention in everything except a handful of obscure programming languages). That frees up dot for record.field. And still we can scratch our heads for something to do with section sign. SS as in set? Some smoother syntax for swifter, saner, salubrious setting. Super! AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 9/02/2012, at 1:26 PM, Evan Laforge wrote: >> How about § then? Surely at this late date we can allow ourselves *one* >> non-ASCII character? >> The very name of it (*section* sign) suggests taking a part; and if you are >> totally in love >> with dot, think of it as a dot with ponytails. > > I suggest record的field, or record之field for the more classically > minded. And why not some synonyms like recordのfield and > recordकाfield, to be inclusive. I chose the most available non-ASCII character I could find. Set the criterion to be "present in most ISO 8-bit character sets" and there are really only two candidates, section sign and degrees sign. That hardly opens flood-gates. It should certainly be limited to characters that do not occur in a word, ruling out record մաս field. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
> How about § then? Surely at this late date we can allow ourselves *one* > non-ASCII character? > The very name of it (*section* sign) suggests taking a part; and if you are > totally in love > with dot, think of it as a dot with ponytails. I suggest record的field, or record之field for the more classically minded. And why not some synonyms like recordのfield and recordकाfield, to be inclusive. Once these floodgates are opened we'll never want for operator names again :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On Wed, Feb 8, 2012 at 2:47 PM, Malcolm Wallace wrote:
> On 8/02/2012, at 14:16, Steve Horne wrote:
>
>>
>> I haven't given a lot of thought to updates.
>>
>
> I very much fail to see the point of replacing prefix function application
> with postfix dots, merely for field selection. There are already some
> imperfect, but adequate, solutions to the problem of global uniqueness of
> field names. But you now have mentioned what is really bothering me about
> this discussion: record updates are simply the most painful and least
> beautiful part of the Haskell syntax. Their verbosity is astonishing
> compared to the careful tenseness of every other language construct. If we
> could spend some effort on designing a decent notation for field updates, I
> think it would be altogether more likely to garner support than fiddling with
> dots.
It's already possible, here's what I've been experimenting with, using fclabels:
import Data.Label
-- | Compose lenses.
(#) :: (a :-> b) -> (b :-> c) -> (a :-> c)
(#) = flip (.)
infixr 9 #
-- | Get: @bval = a#b $# record@
($#) :: (f :-> a) -> f -> a
($#) = get
infixr 1 $#
-- | Set: @a#b =# 42 record@
(=#) :: (f :-> a) -> a -> f -> f
(=#) = set
infix 1 =#
Before:
setTempo :: Y -> Config -> Config
setTempo y config =
config { Config.deflt = (Config.deflt config) { Config.tempo = y } }
After:
setTempo :: Config -> Config
setTempo y = Config.deflt#Config.tempo =# y
I haven't fully integrated this into my project because there are a
lot of labels to convert, but it's promising so far.
As far as I'm concerned, the thing to get rid of is the noisy module
qualification, which was what my suggestion was aimed at. Then we'd
have '#deflt . #tempo =# y', which is pretty concise, if full of #s.
Of course some way to resolve 'deflt' and 'tempo' without ugly #
markers would be nicer, but I think that would have to be typeclass
overloading, which would still require explicit imports for all those
label names. They'd also be uncontrollably global, which wouldn't let
you use them inside the module but not export. So I'm starting to
think that in the absence of changes to typeclasses themselves, a
typeclass-using solution is never going to be satisfactory.
I agree WRT updates, btw. I don't mind the existing record access
very much. It's noisy (I prefix record fields too, so it's even
worse: Config.default_tempo . Config.config_default), but it composes,
so it just means a few more wrapped lines when they don't fit in 80
columns. The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames. I hope I can fix it
with lenses, but it's a bit of a hassle trying to retrofit them onto
something large.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
> record.field (read "record, oops, I only want part of it".) I would read this "record's field" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 9/02/2012, at 3:16 AM, Steve Horne wrote: > On 07/02/2012 22:56, Richard O'Keefe wrote: >> On 8/02/2012, at 2:11 AM, Steve Horne wrote: >> >> >>> To be fair, "field OF record" isn't bad in that sense. However, it would >>> defeat the purpose of TDNR - the record isn't first, and therefore cannot >>> be used (given a left-to-right typing direction) as a context to offer >>> member name suggestions. >>> >> Yes, but why SHOULD there be a specific typing direction? >> ML manages perfectly fine without it. >> > For the only reason that any language feature should exist - because it is > useful. In any language with a rich library, it is useful to get hints as to > which names are available in a particular context. It saves on the need to > memorize thousands - sometimes tens or even hundreds of thousands - of > context-sensitive names and their spellings, and saves on getting distracted > needing to hunt through manuals. You have totally confused me. All of those are good things. NONE of them depends on whether it is field¶record (read "field OF record") or record.field (read "record, oops, I only want part of it".) I think people are losing sight of the fact that code gets read more often than it gets written (at least, if it is code that is _worth_ writing). If the complaint is that certain IDEs designed originally for Java find it easier to give you a hint after "record.", then I would point out that - there is no reason IDEs they cannot be redesigned. Type an expression, then select it if it's complex or don't bother if it's just an identifier, literal, or bracketed, then hit your choice of key (maybe Option-r, ® Reminds me of Record), pick your field from a menu, and the IDE drops field¶ in front of the selected expression and extends the selection to incorporate the field. There is no law of God, Nature, or Man that says the order in which you press the keys has to correspond to the order in which you read things. - languages like C++ and Ada and Java already have the problem that you can write f (x) where the sensible candidates for f depend on what x is. That is, we ALREADY have a need for right context to resolve a left side identifier. Hmm; I was thinking of overloading, but actually, Haskell and C have this problem too. For int x I want close(x) but for FILE* x I want fclose(x). You could write in a C IDE (x, y, z) (hey, it could be © for Call) and have a menu of visible functions with that parameter profile pop up. - if you have thousands of context-sensitive identifiers visible in one module, you *desperately* need a better naming convention and shorter import lists. - I have Pharo open on my screen. There are some 3077 classes in it. It insists on popping up these so-called "helpful" menus of names that match what I've typed so far. I find them distracting, and they tend to obscure what I am doing. I *wish* they didn't do that. But I have to admit that I've never actually seen a long list. There are 30,674 'function names' around (both of the numbers are before any of my code is loaded). Again, I start typing something that could be a function name, and up pops a list of candidates. FEH! Despite Smalltalk's lack of any kind of compile-time type checking (this is Pharo, not Strongtalk), again, I've never seen a long list. So I don't see any reason to warp what people *read* away from readability (function before argument) in order to pander to the imagined limitations of writing tools. - if you have thousands of context-sen > The point here is for intellisense-like features to work effectively in text > editors. The context must come to the left for that to work because... And that is the claim I just demolished. The order in which things are entered and the order in which they are display does not have to be the same. That is, after all, one thing that "wizards" do for you. > That said, I did take a look in an old COBOL book. I didn't find either the > dot or the "OF". That is extremely odd, because while COBOL accepts both "field OF record" and "field IN record", people mostly use "OF". That must have been the world's worst COBOL book. (Not unlike the Prolog textbook I met in a university book shop back when Prolog was new: every single example was syntactically illegal.) > > Haskell already has a . for selecting a name through a context - we call that > context a module. According to Bertrand Meyer of Eiffel fame, a class is both > a module and a type. The Haskell, Ada, Lisp, and CAML designers disagree. > > It would be nice to have some lexical disambiguation in this case - I might > prefer some other spelling, so long as the context is on the left and the > name is on the right. I was going to propose "?", but that's taken already > for implicit parameters - which I don't know the first thing about so I can't > guess possible conflic
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 8/02/2012, at 14:16, Steve Horne wrote: > > I haven't given a lot of thought to updates. > I very much fail to see the point of replacing prefix function application with postfix dots, merely for field selection. There are already some imperfect, but adequate, solutions to the problem of global uniqueness of field names. But you now have mentioned what is really bothering me about this discussion: record updates are simply the most painful and least beautiful part of the Haskell syntax. Their verbosity is astonishing compared to the careful tenseness of every other language construct. If we could spend some effort on designing a decent notation for field updates, I think it would be altogether more likely to garner support than fiddling with dots. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Mersenne-random and standard random API
Hi, I've been in the past told that mersenne-random was much better than the standard random package. However, System.Random.Mersenne doesn't follow the general API described in System.Random, MTGen is not an instance of RandomGen. But a sample on System.Random.Mersenne.getStdRandom documentation ( http://hackage.haskell.org/packages/archive/mersenne-random/1.0.0.1/doc/html/System-Random-Mersenne.html) indicates this: rollDice :: IO Int rollDice = getMTRandom (randomR (1,6)) It looks like wrong documentation (checking of older versions show that getMTRandom have never lived or been exposed by this module), but suggests MTRandom should be an instance of RandomGen (if I assume well that randomR is that of System.Random). So is it possible to use the fast and efficient mersenne generator with the convenient and general random API? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
If you only need one structure for communication (e.g. neither thread needs to lock multiple things) you might consider using an IORef, and writing/polling it with atomicModifyIORef. It's cheaper than an MVar for the case where you don't need to lock multiple threads. On Wed, Feb 8, 2012 at 2:45 PM, JP Moresmau wrote: > No, I meant they seem to be mainly for the use case where the reading > thread blocks for more input, and maybe there's a simpler/more > efficient way to quickly check if an event has occurred, that's all. > If there isn't then a MVar it will be. > > JP > > On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès wrote: >> Why do you think it's a lot? MVar are a teeny tiny and convenient primitive >> of communication, and I don't see why they wouldn't suit your need. >> Sure a throwTo would do the trick... But they're is "do the trick" and "do >> the job", you see? >> >> Using STM and TVars *would* be kind of overkill. >> >> >> 2012/2/8 JP Moresmau >>> >>> Hello, I'm wondering what's the best strategy to use in the following >>> scenario: >>> - 2 threads >>> - One perform some work that will take time, possibly go on forever >>> - Another waits for user input (like commands from the keyboard) >>> that affects thread 1 (causing it to stop, in the simplest case) >>> >>> I've read a bit on MVar and channels, but they seem to be a lot for >>> cases where the reading thread block for input. In my case, I expect >>> to have "something" that thread 2 updates when an event occur, and >>> thread 1 checks it regularly. So thread 1 should not block, but should >>> check "is there something" and there is, act on it, otherwise continue >>> doing what it was currently doing. I suppose I could just tryTakeMVar >>> on a MVar, but is there something more adapted to my needs? >>> >>> Thanks! >>> >>> -- >>> JP Moresmau >>> http://jpmoresmau.blogspot.com/ >>> >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be. JP On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès wrote: > Why do you think it's a lot? MVar are a teeny tiny and convenient primitive > of communication, and I don't see why they wouldn't suit your need. > Sure a throwTo would do the trick... But they're is "do the trick" and "do > the job", you see? > > Using STM and TVars *would* be kind of overkill. > > > 2012/2/8 JP Moresmau >> >> Hello, I'm wondering what's the best strategy to use in the following >> scenario: >> - 2 threads >> - One perform some work that will take time, possibly go on forever >> - Another waits for user input (like commands from the keyboard) >> that affects thread 1 (causing it to stop, in the simplest case) >> >> I've read a bit on MVar and channels, but they seem to be a lot for >> cases where the reading thread block for input. In my case, I expect >> to have "something" that thread 2 updates when an event occur, and >> thread 1 checks it regularly. So thread 1 should not block, but should >> check "is there something" and there is, act on it, otherwise continue >> doing what it was currently doing. I suppose I could just tryTakeMVar >> on a MVar, but is there something more adapted to my needs? >> >> Thanks! >> >> -- >> JP Moresmau >> http://jpmoresmau.blogspot.com/ >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
I will merge this as soon as I get back from vacation. On Feb 8, 2012 8:54 AM, "Holger Reinhardt" wrote: > Having discussed the issue privately with Alberto, I've found another bug > and updated my pull request [1]. Using that code it should be possible to > build the network library on Windows using MSys on GHC 7.4.1. > > [1] https://github.com/haskell/network/pull/25 > > 2012/2/8 Alberto G. Corona > >> yes i did it,. >> >> the error is as follows: >> >> shop.exe: NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in >> case >> >> I will download network form hackage and will do it form the beginning. . >> >> >> >> 2012/2/8 Holger Reinhardt : >> > Did you run "cabal clean" before rebuilding with Git Bash? And can you >> post >> > the exact runtime error you get? >> > >> > 2012/2/8 Alberto G. Corona >> > >> >> I switched to Git bash and the runtime error produced by the library >> >> is the same. >> >> This error may be produced because the configuration it does not >> >> detect the netwiorkin related includes such is socket.h. This does not >> >> exist neither in the ghc installation neither in GIT/Mingw >> >> >> >> >> >> 2012/2/7 Holger Reinhardt : >> >> > I just use the version of MSys that is included with Git [1]. This >> puts >> >> > a >> >> > "Git bash" icon on your desktop which you can then use to build the >> >> > network >> >> > library. >> >> > >> >> > [1] http://code.google.com/p/msysgit/ >> >> > >> >> > >> >> > 2012/2/7 Alberto G. Corona >> >> >> >> >> >> Nothing bur a long history of failures. The problem is the >> >> >> configuration and versioning of MinGW and MSys. This is a nighmare. >> >> >> >> >> >> 2012/2/7 Holger Reinhardt : >> >> >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot >> >> >> > reproduce >> >> >> > your problem. Is there anything preventing you from using MSys? >> >> >> > >> >> >> > >> >> >> > 2012/2/7 Alberto G. Corona >> >> >> >> >> >> >> >> The "problem" this time is in "Configure" : >> >> >> >> >> >> >> >> case "$host" in >> >> >> >> *-mingw32) >> >> >> >>EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, >> >> >> >> cbits/asyncAccept.c" >> >> >> >>EXTRA_LIBS=ws2_32 >> >> >> >>CALLCONV=stdcall ;; >> >> >> >> *-solaris2*) >> >> >> >>EXTRA_SRCS="cbits/ancilData.c" >> >> >> >>EXTRA_LIBS="nsl, socket" >> >> >> >>CALLCONV=ccall ;; >> >> >> >> *) >> >> >> >>EXTRA_SRCS="cbits/ancilData.c" >> >> >> >>EXTRA_LIBS= >> >> >> >>CALLCONV=ccall ;; >> >> >> >> esac >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Since I´m cross-compiling with cygwin, the variable Host does not >> >> >> >> contain ¨*-muingw32" but "i686-pc-cygwin" >> >> >> >> >> >> >> >> changing the case , the library incorporates the lost C coded >> files. >> >> >> >> >> >> >> >> Now the library links fine win imported, but there is a runtime >> >> >> >> error: >> >> >> >> >> >> >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in >> case >> >> >> >> >> >> >> >> maybe it is due to some other preprocessor directive mismatch >> >> >> >> >> >> >> >> >> >> >> >> 2012/2/7 Holger Reinhardt : >> >> >> >> > Did you also change the files in the /cbits/ folder? Because >> they >> >> >> >> > also >> >> >> >> > check >> >> >> >> > for HAVE_WINSOCK_H. >> >> >> >> > >> >> >> >> > >> >> >> >> > 2012/2/7 Alberto G. Corona >> >> >> >> >> >> >> >> >> >> The code is evolving and none of the versions match exactily >> with >> >> >> >> >> the >> >> >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these >> >> >> >> >> files >> >> >> >> >> solves the compilation problem at least in the network >> 2.3.0.10 >> >> >> >> >> version from hackage. >> >> >> >> >> >> >> >> >> >> However it produces the same undefined references when this >> >> >> >> >> library >> >> >> >> >> is >> >> >> >> >> imported in my application. It seems that some object code is >> not >> >> >> >> >> included in the final library. I verified that at least some >> of >> >> >> >> >> these >> >> >> >> >> undefined references correspond with C code in the source, >> but >> >> >> >> >> somehow this is not included in the object library >> >> >> >> >> >> >> >> >> >> 2012/2/7 Johan Tibell : >> >> >> >> >> > Note that there are two branches on github, master and >> stable. >> >> >> >> >> > You >> >> >> >> >> > want >> >> >> >> >> > the >> >> >> >> >> > latter. >> >> >> >> >> > >> >> >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" >> >> >> >> >> > >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> This is quite different. >> >> >> >> >> >> I don´t know how but I was looking at some other older >> patch >> >> >> >> >> >> around >> >> >> >> >> >> the same issue and I supposed that it was the one refered >> by >> >> >> >> >> >> Yohan >> >> >> >> >> >> Tibell. >> >> >> >> >> >> >> >> >> >> >> >> I´ll try your patch. >> >> >> >> >> >> >> >> >> >> >> >> Thanks!. >> >> >> >> >> >> >> >> >> >> >> >> 2012/2/7 Holger Reinh
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Tue, Feb 07, 2012 at 06:26:48PM -0800, John Meacham wrote: > > Hi, from my reading, it looks like 'capi' means from a logical perspective, > > "Don't assume the object is addressible, but rather that the standard c syntax > for calling this routine will expand into correct code when compiled with the > stated headers" > > So, it may be implemented by say creating a stub .c file that includes the > headers and creates a wrapper around each one or when compiling via C, > actually including the given headers and the function calls in the code. That sounds right. It basically means you don't have to write the C stubs yourself, which is nice because (a) doing so is a pain, and (b) when the foreign import is inside 2 or 3 CPP conditionals it's even more of a pain to replicate them correctly in the C stub. Unfortunately, there are cases where C doesn't get all the type information it needs, e.g.: http://hackage.haskell.org/trac/ghc/ticket/2979#comment:14 but I'm not sure what the best fix is. > I ask because jhc needs such a feature (very hacky method used now, > the rts knows some problematic functions and includes hacky wrappers > and #defines.) and I'll make it behave just like the ghc one when possible. Great! Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
Having discussed the issue privately with Alberto, I've found another bug and updated my pull request [1]. Using that code it should be possible to build the network library on Windows using MSys on GHC 7.4.1. [1] https://github.com/haskell/network/pull/25 2012/2/8 Alberto G. Corona > yes i did it,. > > the error is as follows: > > shop.exe: NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in > case > > I will download network form hackage and will do it form the beginning. . > > > > 2012/2/8 Holger Reinhardt : > > Did you run "cabal clean" before rebuilding with Git Bash? And can you > post > > the exact runtime error you get? > > > > 2012/2/8 Alberto G. Corona > > > >> I switched to Git bash and the runtime error produced by the library > >> is the same. > >> This error may be produced because the configuration it does not > >> detect the netwiorkin related includes such is socket.h. This does not > >> exist neither in the ghc installation neither in GIT/Mingw > >> > >> > >> 2012/2/7 Holger Reinhardt : > >> > I just use the version of MSys that is included with Git [1]. This > puts > >> > a > >> > "Git bash" icon on your desktop which you can then use to build the > >> > network > >> > library. > >> > > >> > [1] http://code.google.com/p/msysgit/ > >> > > >> > > >> > 2012/2/7 Alberto G. Corona > >> >> > >> >> Nothing bur a long history of failures. The problem is the > >> >> configuration and versioning of MinGW and MSys. This is a nighmare. > >> >> > >> >> 2012/2/7 Holger Reinhardt : > >> >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot > >> >> > reproduce > >> >> > your problem. Is there anything preventing you from using MSys? > >> >> > > >> >> > > >> >> > 2012/2/7 Alberto G. Corona > >> >> >> > >> >> >> The "problem" this time is in "Configure" : > >> >> >> > >> >> >> case "$host" in > >> >> >> *-mingw32) > >> >> >>EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, > >> >> >> cbits/asyncAccept.c" > >> >> >>EXTRA_LIBS=ws2_32 > >> >> >>CALLCONV=stdcall ;; > >> >> >> *-solaris2*) > >> >> >>EXTRA_SRCS="cbits/ancilData.c" > >> >> >>EXTRA_LIBS="nsl, socket" > >> >> >>CALLCONV=ccall ;; > >> >> >> *) > >> >> >>EXTRA_SRCS="cbits/ancilData.c" > >> >> >>EXTRA_LIBS= > >> >> >>CALLCONV=ccall ;; > >> >> >> esac > >> >> >> > >> >> >> > >> >> >> > >> >> >> Since I´m cross-compiling with cygwin, the variable Host does not > >> >> >> contain ¨*-muingw32" but "i686-pc-cygwin" > >> >> >> > >> >> >> changing the case , the library incorporates the lost C coded > files. > >> >> >> > >> >> >> Now the library links fine win imported, but there is a runtime > >> >> >> error: > >> >> >> > >> >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in > case > >> >> >> > >> >> >> maybe it is due to some other preprocessor directive mismatch > >> >> >> > >> >> >> > >> >> >> 2012/2/7 Holger Reinhardt : > >> >> >> > Did you also change the files in the /cbits/ folder? Because > they > >> >> >> > also > >> >> >> > check > >> >> >> > for HAVE_WINSOCK_H. > >> >> >> > > >> >> >> > > >> >> >> > 2012/2/7 Alberto G. Corona > >> >> >> >> > >> >> >> >> The code is evolving and none of the versions match exactily > with > >> >> >> >> the > >> >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these > >> >> >> >> files > >> >> >> >> solves the compilation problem at least in the network 2.3.0.10 > >> >> >> >> version from hackage. > >> >> >> >> > >> >> >> >> However it produces the same undefined references when this > >> >> >> >> library > >> >> >> >> is > >> >> >> >> imported in my application. It seems that some object code is > not > >> >> >> >> included in the final library. I verified that at least some > of > >> >> >> >> these > >> >> >> >> undefined references correspond with C code in the source, but > >> >> >> >> somehow this is not included in the object library > >> >> >> >> > >> >> >> >> 2012/2/7 Johan Tibell : > >> >> >> >> > Note that there are two branches on github, master and > stable. > >> >> >> >> > You > >> >> >> >> > want > >> >> >> >> > the > >> >> >> >> > latter. > >> >> >> >> > > >> >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" > >> >> >> >> > > >> >> >> >> > wrote: > >> >> >> >> >> > >> >> >> >> >> This is quite different. > >> >> >> >> >> I don´t know how but I was looking at some other older patch > >> >> >> >> >> around > >> >> >> >> >> the same issue and I supposed that it was the one refered by > >> >> >> >> >> Yohan > >> >> >> >> >> Tibell. > >> >> >> >> >> > >> >> >> >> >> I´ll try your patch. > >> >> >> >> >> > >> >> >> >> >> Thanks!. > >> >> >> >> >> > >> >> >> >> >> 2012/2/7 Holger Reinhardt : > >> >> >> >> >> > Hi, > >> >> >> >> >> > > >> >> >> >> >> > (I submitted the patch that Johan linked to) > >> >> >> >> >> > Network/Socket/Internal.hsc has the following code: > >> >> >> >> >> > > >> >> >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_H
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
Why do you think it's a lot? MVar are a teeny tiny and convenient primitive of communication, and I don't see why they wouldn't suit your need. Sure a throwTo would do the trick... But they're is "do the trick" and "do the job", you see? Using STM and TVars *would* be kind of overkill. 2012/2/8 JP Moresmau > Hello, I'm wondering what's the best strategy to use in the following > scenario: > - 2 threads > - One perform some work that will take time, possibly go on forever > - Another waits for user input (like commands from the keyboard) > that affects thread 1 (causing it to stop, in the simplest case) > > I've read a bit on MVar and channels, but they seem to be a lot for > cases where the reading thread block for input. In my case, I expect > to have "something" that thread 2 updates when an event occur, and > thread 1 checks it regularly. So thread 1 should not block, but should > check "is there something" and there is, act on it, otherwise continue > doing what it was currently doing. I suppose I could just tryTakeMVar > on a MVar, but is there something more adapted to my needs? > > Thanks! > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
You could use throwTo to raise an exception in the thread you want to stop. Otherwise, having some variable (IORef, TVar, MVar) that the long running thread occasionally checks seems like a good solution. Erik On Wed, Feb 8, 2012 at 17:04, JP Moresmau wrote: > Hello, I'm wondering what's the best strategy to use in the following > scenario: > - 2 threads > - One perform some work that will take time, possibly go on forever > - Another waits for user input (like commands from the keyboard) > that affects thread 1 (causing it to stop, in the simplest case) > > I've read a bit on MVar and channels, but they seem to be a lot for > cases where the reading thread block for input. In my case, I expect > to have "something" that thread 2 updates when an event occur, and > thread 1 checks it regularly. So thread 1 should not block, but should > check "is there something" and there is, act on it, otherwise continue > doing what it was currently doing. I suppose I could just tryTakeMVar > on a MVar, but is there something more adapted to my needs? > > Thanks! > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Concurrency strategy for 2 threads and rare events
Hello, I'm wondering what's the best strategy to use in the following scenario: - 2 threads - One perform some work that will take time, possibly go on forever - Another waits for user input (like commands from the keyboard) that affects thread 1 (causing it to stop, in the simplest case) I've read a bit on MVar and channels, but they seem to be a lot for cases where the reading thread block for input. In my case, I expect to have "something" that thread 2 updates when an event occur, and thread 1 checks it regularly. So thread 1 should not block, but should check "is there something" and there is, act on it, otherwise continue doing what it was currently doing. I suppose I could just tryTakeMVar on a MVar, but is there something more adapted to my needs? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yesod and dependencies hell
For three days I can't compile dependencies for my project using yesod, yesod-auth, yesod-persistent, persistent-template, persistent-sqlite, persistent. When I varied version I received a variety of broken dependencies: persistent (0.6.* vs 0.7.*), conduit (0.1.* vs 0.2.*), conduit-pool, path-pieces, attoparsec and something else. In this regard, I have a few questions. How to build these packages together? And, Michael, why so bad? -- Тимофеев Н.Д. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The State of Testing?
Thanks Thomas, that new flag is great. Mike Craig On Tue, Feb 7, 2012 at 10:03 PM, Thomas Tuegel wrote: > On Tue, Feb 7, 2012 at 3:23 PM, Austin Seipp wrote: > > If you're writing a library, you need to compile the library with > > `-fhpc`, i.e. put it in the library stanza, not the testsuite stanza, > > and then you can compile the test program using your library - the > > resulting 'tix' file will contain the library coverage reports. You > > can link a HPC-built library into an executable not compiled with HPC > > just fine. > > > > Normally I only compile the library under HPC mode, link it in a test, > > and distribute the results from that. That way your coverage reports > > don't include the test module (which may or may not be relevant.) > > > > I normally add a cabal flag called 'hpc' which optionally enables > > coverage reports for my library, e.g. > > > > flag hpc > > default: False > > > > library > > ... > > ... > > if flag(hpc) > >ghc-options: -fhpc > > > > Then when you want coverage reports, just say 'cabal install -fhpc > > --enable-tests' and the resulting properties executable will spit out > > the results when run. > > First, as author of the test suite code, let me apologize for the > terrible documentation. > > This is absolutely NOT how coverage reports are supposed to work. If > you configure with '--enable-tests --enable-library-coverage', Cabal > will take care of _everything_ else for you, including excluding the > test module from the coverage report. You should not have to put any > flag gymnastics in your .cabal file. > > If this doesn't work for you, please let me know, because it's a bug. > > Thanks! > > -- > Thomas Tuegel > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 07/02/2012 22:56, Richard O'Keefe wrote: On 8/02/2012, at 2:11 AM, Steve Horne wrote: To be fair, "field OF record" isn't bad in that sense. However, it would defeat the purpose of TDNR - the record isn't first, and therefore cannot be used (given a left-to-right typing direction) as a context to offer member name suggestions. Yes, but why SHOULD there be a specific typing direction? ML manages perfectly fine without it. For the only reason that any language feature should exist - because it is useful. In any language with a rich library, it is useful to get hints as to which names are available in a particular context. It saves on the need to memorize thousands - sometimes tens or even hundreds of thousands - of context-sensitive names and their spellings, and saves on getting distracted needing to hunt through manuals. - #1; stdIn:1.1-1.3 Error: unresolved flex record (can't tell what fields there are besides #1) - #1 (true,3); val it = true : bool - #1 (42,"stuff",false); val it = 42 : int If a right-to-left "typing direction" works well for #field record in one language with constrained Hindley-Milner types, why would it not work well for field¶ record in another language with constrained Hindley-Milner types? Parsers don't need to care much about left-to-right vs. right-to-left. There can be stack size issues in principle, but that hasn't stopped Haskell offering both left-associative and right-associative infix operators. The ordering has significance in certain ways in functional languages WRT e.g. currying, but that isn't really relevant here. In any case, currying is left-to-right anyway - the left-most argument is curried first. The point here is for intellisense-like features to work effectively in text editors. The context must come to the left for that to work because... 1. Searching for all possible names within a particular context is easier, and generally more likely to be what is needed, than searching for all possible contexts that contain a particular name. 2. It's easier to type the context, then the marker, then select/type the name than it is to type the marker then the context, then cursor back to before the marker, *then* select the name, then cursor back to after the context. Why sacrifice readability (field name precedes record) for the sake of, well, for the sake of what exactly escapes me. It doesn't sacrifice readability. The left-to-right order has been chosen by most programming languages, and also used in many other contexts, because many people find it very natural to start from the most general and step down to the more specific in a left-to-right direction. For example, .., or //. The left-to-right order isn't especially important in general - but for intellisense it is. Also, even when I used COBOL (late eightees, early nineties) I'm pretty sure it supported "record.field". That certainly wasn't the case up to COBOL-85. I don't have a copy of COBOL 2002, so I can't speak for that, but COBOL 74 and COBOL 85 are the only candidates for those dates, and they definitely did NOT support record.field. Since '.' is the statement terminator in COBOL, it's intrinsically unlikely. (You did *check* a COBOL syntax summary, easily found on the web, before posting? Which?) If I checked, I wouldn't have said "pretty sure" would I? Those words are generally acknowledged as indicating that someone is working from fallible memory. That said, I did take a look in an old COBOL book. I didn't find either the dot or the "OF". I vaguely remember that the original COBOL textbook I had actually considered the SORT command so intrinsically difficult that it was outside of the scope of the book. For various reasons, I find it difficult to take COBOL seriously at all, though I wish I had kept that original textbook that didn't cover SORT - it was a much better joke than the book I kept. On the more general point of choosing an alternative operator, I agree to a point, but familiarity does count for something. Others will point out that Haskell dares to be different, but it's possible to be too daring and too different. Being different for the sake of being different is for those teenagers who go on about being "random" and whatever else they go on about these days. The success of languages like Java, C# and C++ is based on familiarity. Using pointy brackets for generic parameters and :: for name scope were not familiar when C++ introduced them. And there was prior art in other languages for *both* of those. One common prior practice, relevantly enough, was '.' for name scope. Yes, but C++ also dares to be different, and there's a principled reason for having multiple selection operators in C++. There are multiple namespaces involved. For a smart pointer, for example, . and -> access different namespaces. :: accesses a different namespace too - containing the mostly the same names, but treating them a dif
Re: [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
yes i did it,. the error is as follows: shop.exe: NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in case I will download network form hackage and will do it form the beginning. . 2012/2/8 Holger Reinhardt : > Did you run "cabal clean" before rebuilding with Git Bash? And can you post > the exact runtime error you get? > > 2012/2/8 Alberto G. Corona > >> I switched to Git bash and the runtime error produced by the library >> is the same. >> This error may be produced because the configuration it does not >> detect the netwiorkin related includes such is socket.h. This does not >> exist neither in the ghc installation neither in GIT/Mingw >> >> >> 2012/2/7 Holger Reinhardt : >> > I just use the version of MSys that is included with Git [1]. This puts >> > a >> > "Git bash" icon on your desktop which you can then use to build the >> > network >> > library. >> > >> > [1] http://code.google.com/p/msysgit/ >> > >> > >> > 2012/2/7 Alberto G. Corona >> >> >> >> Nothing bur a long history of failures. The problem is the >> >> configuration and versioning of MinGW and MSys. This is a nighmare. >> >> >> >> 2012/2/7 Holger Reinhardt : >> >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot >> >> > reproduce >> >> > your problem. Is there anything preventing you from using MSys? >> >> > >> >> > >> >> > 2012/2/7 Alberto G. Corona >> >> >> >> >> >> The "problem" this time is in "Configure" : >> >> >> >> >> >> case "$host" in >> >> >> *-mingw32) >> >> >> EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, >> >> >> cbits/asyncAccept.c" >> >> >> EXTRA_LIBS=ws2_32 >> >> >> CALLCONV=stdcall ;; >> >> >> *-solaris2*) >> >> >> EXTRA_SRCS="cbits/ancilData.c" >> >> >> EXTRA_LIBS="nsl, socket" >> >> >> CALLCONV=ccall ;; >> >> >> *) >> >> >> EXTRA_SRCS="cbits/ancilData.c" >> >> >> EXTRA_LIBS= >> >> >> CALLCONV=ccall ;; >> >> >> esac >> >> >> >> >> >> >> >> >> >> >> >> Since I´m cross-compiling with cygwin, the variable Host does not >> >> >> contain ¨*-muingw32" but "i686-pc-cygwin" >> >> >> >> >> >> changing the case , the library incorporates the lost C coded files. >> >> >> >> >> >> Now the library links fine win imported, but there is a runtime >> >> >> error: >> >> >> >> >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in case >> >> >> >> >> >> maybe it is due to some other preprocessor directive mismatch >> >> >> >> >> >> >> >> >> 2012/2/7 Holger Reinhardt : >> >> >> > Did you also change the files in the /cbits/ folder? Because they >> >> >> > also >> >> >> > check >> >> >> > for HAVE_WINSOCK_H. >> >> >> > >> >> >> > >> >> >> > 2012/2/7 Alberto G. Corona >> >> >> >> >> >> >> >> The code is evolving and none of the versions match exactily with >> >> >> >> the >> >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these >> >> >> >> files >> >> >> >> solves the compilation problem at least in the network 2.3.0.10 >> >> >> >> version from hackage. >> >> >> >> >> >> >> >> However it produces the same undefined references when this >> >> >> >> library >> >> >> >> is >> >> >> >> imported in my application. It seems that some object code is not >> >> >> >> included in the final library. I verified that at least some of >> >> >> >> these >> >> >> >> undefined references correspond with C code in the source, but >> >> >> >> somehow this is not included in the object library >> >> >> >> >> >> >> >> 2012/2/7 Johan Tibell : >> >> >> >> > Note that there are two branches on github, master and stable. >> >> >> >> > You >> >> >> >> > want >> >> >> >> > the >> >> >> >> > latter. >> >> >> >> > >> >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" >> >> >> >> > >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> This is quite different. >> >> >> >> >> I don´t know how but I was looking at some other older patch >> >> >> >> >> around >> >> >> >> >> the same issue and I supposed that it was the one refered by >> >> >> >> >> Yohan >> >> >> >> >> Tibell. >> >> >> >> >> >> >> >> >> >> I´ll try your patch. >> >> >> >> >> >> >> >> >> >> Thanks!. >> >> >> >> >> >> >> >> >> >> 2012/2/7 Holger Reinhardt : >> >> >> >> >> > Hi, >> >> >> >> >> > >> >> >> >> >> > (I submitted the patch that Johan linked to) >> >> >> >> >> > Network/Socket/Internal.hsc has the following code: >> >> >> >> >> > >> >> >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS) >> >> >> >> >> > type CSaFamily = (#type unsigned short) >> >> >> >> >> > #elif defined(darwin_HOST_OS) >> >> >> >> >> > type CSaFamily = (#type u_char) >> >> >> >> >> > #else >> >> >> >> >> > type CSaFamily = (#type sa_family_t) >> >> >> >> >> > #endif >> >> >> >> >> > >> >> >> >> >> > You have patched this part to always use 'unsigned short'. >> >> >> >> >> > But >> >> >> >> >> > the >> >> >> >> >> > real >> >> >> >> >> > issue is that WITH_WINSOCK is not defined, even though it >> >> >> >> >> > should >> >> >> >> >> > be. The >> >> >> >> >> > reason f
Re: [Haskell-cafe] The State of Testing?
Hello Thomas, On Wed, Feb 8, 2012 at 4:03 AM, Thomas Tuegel wrote: > First, as author of the test suite code, let me apologize for the > terrible documentation. > > This is absolutely NOT how coverage reports are supposed to work. If > you configure with '--enable-tests --enable-library-coverage', Cabal > will take care of _everything_ else for you, including excluding the > test module from the coverage report. You should not have to put any > flag gymnastics in your .cabal file. > I get only "cabal: unrecognized option `--enable-library-coverage'" when doing that. Which cabal version do I need? Can you point me to any docs about this? I'm still using test type exitcode-stdio-1.0, because I could not get detailed-1.0 to work. TIA, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
Did you run "cabal clean" before rebuilding with Git Bash? And can you post the exact runtime error you get? 2012/2/8 Alberto G. Corona > I switched to Git bash and the runtime error produced by the library > is the same. > This error may be produced because the configuration it does not > detect the netwiorkin related includes such is socket.h. This does not > exist neither in the ghc installation neither in GIT/Mingw > > > 2012/2/7 Holger Reinhardt : > > I just use the version of MSys that is included with Git [1]. This puts a > > "Git bash" icon on your desktop which you can then use to build the > network > > library. > > > > [1] http://code.google.com/p/msysgit/ > > > > > > 2012/2/7 Alberto G. Corona > >> > >> Nothing bur a long history of failures. The problem is the > >> configuration and versioning of MinGW and MSys. This is a nighmare. > >> > >> 2012/2/7 Holger Reinhardt : > >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot > >> > reproduce > >> > your problem. Is there anything preventing you from using MSys? > >> > > >> > > >> > 2012/2/7 Alberto G. Corona > >> >> > >> >> The "problem" this time is in "Configure" : > >> >> > >> >> case "$host" in > >> >> *-mingw32) > >> >>EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, > >> >> cbits/asyncAccept.c" > >> >>EXTRA_LIBS=ws2_32 > >> >>CALLCONV=stdcall ;; > >> >> *-solaris2*) > >> >>EXTRA_SRCS="cbits/ancilData.c" > >> >>EXTRA_LIBS="nsl, socket" > >> >>CALLCONV=ccall ;; > >> >> *) > >> >>EXTRA_SRCS="cbits/ancilData.c" > >> >>EXTRA_LIBS= > >> >>CALLCONV=ccall ;; > >> >> esac > >> >> > >> >> > >> >> > >> >> Since I´m cross-compiling with cygwin, the variable Host does not > >> >> contain ¨*-muingw32" but "i686-pc-cygwin" > >> >> > >> >> changing the case , the library incorporates the lost C coded files. > >> >> > >> >> Now the library links fine win imported, but there is a runtime > error: > >> >> > >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in case > >> >> > >> >> maybe it is due to some other preprocessor directive mismatch > >> >> > >> >> > >> >> 2012/2/7 Holger Reinhardt : > >> >> > Did you also change the files in the /cbits/ folder? Because they > >> >> > also > >> >> > check > >> >> > for HAVE_WINSOCK_H. > >> >> > > >> >> > > >> >> > 2012/2/7 Alberto G. Corona > >> >> >> > >> >> >> The code is evolving and none of the versions match exactily with > >> >> >> the > >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these > files > >> >> >> solves the compilation problem at least in the network 2.3.0.10 > >> >> >> version from hackage. > >> >> >> > >> >> >> However it produces the same undefined references when this > library > >> >> >> is > >> >> >> imported in my application. It seems that some object code is not > >> >> >> included in the final library. I verified that at least some of > >> >> >> these > >> >> >> undefined references correspond with C code in the source, but > >> >> >> somehow this is not included in the object library > >> >> >> > >> >> >> 2012/2/7 Johan Tibell : > >> >> >> > Note that there are two branches on github, master and stable. > You > >> >> >> > want > >> >> >> > the > >> >> >> > latter. > >> >> >> > > >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" < > agocor...@gmail.com> > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> This is quite different. > >> >> >> >> I don´t know how but I was looking at some other older patch > >> >> >> >> around > >> >> >> >> the same issue and I supposed that it was the one refered by > >> >> >> >> Yohan > >> >> >> >> Tibell. > >> >> >> >> > >> >> >> >> I´ll try your patch. > >> >> >> >> > >> >> >> >> Thanks!. > >> >> >> >> > >> >> >> >> 2012/2/7 Holger Reinhardt : > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > (I submitted the patch that Johan linked to) > >> >> >> >> > Network/Socket/Internal.hsc has the following code: > >> >> >> >> > > >> >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS) > >> >> >> >> > type CSaFamily = (#type unsigned short) > >> >> >> >> > #elif defined(darwin_HOST_OS) > >> >> >> >> > type CSaFamily = (#type u_char) > >> >> >> >> > #else > >> >> >> >> > type CSaFamily = (#type sa_family_t) > >> >> >> >> > #endif > >> >> >> >> > > >> >> >> >> > You have patched this part to always use 'unsigned short'. > But > >> >> >> >> > the > >> >> >> >> > real > >> >> >> >> > issue is that WITH_WINSOCK is not defined, even though it > >> >> >> >> > should > >> >> >> >> > be. The > >> >> >> >> > reason for this lies in include/HsNet.h: > >> >> >> >> > > >> >> >> >> > #if defined(HAVE_WINSOCK_H) && !defined(cygwin32_HOST_OS) > >> >> >> >> > # define WITH_WINSOCK 1 > >> >> >> >> > #endif > >> >> >> >> > > >> >> >> >> > The problem here is that it checks for HAVE_WINSOCK_H, but > the > >> >> >> >> > configure > >> >> >> >> > script never defines this variable. Instead it > >> >> >> >> > defines HAVE_WINSOCK2_
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On 08/02/2012 02:26, John Meacham wrote: On Tue, Feb 7, 2012 at 4:24 AM, Simon Marlow wrote: Separately the unix package added support for undecoded FilePaths (RawFilePath), but unfortunately at the same time we started using a new extension in GHC 7.4.1 (CApiFFI), which we decided not to document because it was still experimental: Hi, from my reading, it looks like 'capi' means from a logical perspective, "Don't assume the object is addressible, but rather that the standard c syntax for calling this routine will expand into correct code when compiled with the stated headers" So, it may be implemented by say creating a stub .c file that includes the headers and creates a wrapper around each one or when compiling via C, actually including the given headers and the function calls in the code. Yes, that's exactly it. In GHC we create a stub (even when compiling via C, for simplicity of implementation). Cheers, Simon I ask because jhc needs such a feature (very hacky method used now, the rts knows some problematic functions and includes hacky wrappers and #defines.) and I'll make it behave just like the ghc one when possible. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
