[Haskell-cafe] GHC users on PowerPC and *BSD/Darwin?
Hi all, Users of GHC on PowerPC would probably be aware of this bug: http://hackage.haskell.org/trac/ghc/ticket/2972 which causes GHCi to segfault as soon as it was started. Ben M. Collins has come up with a fix for this I am preparing it for submission to the GHC git tree. I have have tested it on linux-powerpc, but would also like to test it on *BSD/Darwin. Anybody out there interested? You will need: * A PowerPC machine running *BSD or Darwin. * A working GHC compiler. If you're interested email me at erikd AT mega-nerd dot com. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monad with limited backtracking
Kind Sirs/Madams,
Thanks in advance for your patience; the solution will no doubt be obvious to
those with greater experience than me. I have formulated a monad to provide
limited backtracking for implementing a rewrite system. The success case works
fine, but my intention is that on failure the result should contain the list of
input symbols consumed up to the failure, and it is this part that I would
like some advice about. Code follows:
---
import Control.Monad
import Debug.Trace
newtype Rewrite a b = Rewrite { run :: Input a -> Result a b }
data Input a = Input [a]
data Result a b = Fail [a] | Ok b [a]
deriving (Eq, Show)
instance (Show a) => Monad (Rewrite a) where
return y = Rewrite $ \(Input xs) -> Ok y xs
p >>= f = Rewrite $ \inp ->
case run p inp of
Fail xs -> trace ("1.xs=" ++ show xs) $
Fail xs
Ok y xs -> case run (f y) (Input xs) of
Fail xs' -> trace ("2.xs=" ++ show xs) $
Fail xs
okay -> okay
instance (Show a) => MonadPlus (Rewrite a) where
mzero = Rewrite $ \inp -> Fail []
p `mplus` q = Rewrite $ \inp -> case run p inp of
Fail _ -> run q inp
okay -> okay
(>>=?) ::(Show a) => Rewrite a b -> (b -> Bool) -> Rewrite a b
p >>=? f = p >>= \y -> guard (f y) >> return y
next :: Rewrite a a
next = Rewrite $ \(Input xs) -> case xs of
[] -> Fail []
(x:xs') -> Ok x xs'
exactly :: (Show a, Eq a) => [a] -> Rewrite a [a]
exactly = mapM $ \i -> next >>=? (==i)
---
For example, using ghci:
*Main> run (exactly [1,2]) (Input [1,2,3,4])
Ok [1,2] [3,4]
which is what I intend. However, while the thing correctly reports failure, I
cannot get it to return the list of symbols up to the point of failure:
*Main> run (exactly [1,2,3]) (Input [1,2,7,4])
1.xs=[]
2.xs=[4]
1.xs=[4]
1.xs=[4]
2.xs=[7,4]
1.xs=[7,4]
2.xs=[2,7,4]
Fail [2,7,4] *I would like Fail [1,2] here instead*
I thank you in advance for any guidance you might offer.
Dr Darryn J Reid.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Solutions for multi-platform compilation?
Hi, I work developing multi-platform applications in Haskell. This poses the following problem: I cannot compile binaries for windows from linux (AFAIK). I "solved" this problem with the following sledgehammer: I installed windows in a VM, I installed GHC, I installed all the C/C++ headers & binaries of the libraries that I use (Gtk, OpenGL, SDL, OpenCV, etc.) their Haskell counterparts, and I created several scripts that connect to the VM using SSH, push the changes to the repo, cabal clean & cabal install all my packages in sequence without me having to even login into the windows machine. I did this because I was unable to get GHC to run properly in Wine at that time (over 2 years ago). This solution is still unsatisfactory because: 1) It's slow, even though Windows itself works fine (well, as well as windows can work, but it runs at a decent spped, I can play games and all). 2) When I update a library with lots of dependencies, or GHC itself, I have to rebuild almost everything. This is particularly painful with big packages like Gtk, for instance. Because I have to tell cabal where headers and libraries are located, updating a package is almost never an automatic process. I haven't always been able to make GHC "just pick them up" properly with pkg-config. 3) When I make a change in a library with lots of dependencies, recompiling all the packages can take several hours. I don't think it's a problem with my machine: I'm giving a fair amount of resources to windows, and I use a 3Ghz quadcore with 8GB of RAM. Another relevant fact is: I use this for commercial purposes. I have customers, each requiring a completely different program, they do not have infinite budgets and, if there's a problem in the compilation process and something requires my attention and manual intervention too often, my salary per hour can easily drop to a ridiculous amount. If I'm going to redo this, I'd rather just redo it once. Any suggestions? How do you solve this kind of problem in your work environment? Cheers, Ivan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lazy boxed array and builder?
he recent discussion of whether storablevector should be deprecated in favor of vector reminded me: vector supports storable arrays, but it doesn't support lazy arrays. While storablevector has lazy arrays and a builder, it doesn't support boxed types (it would be become misnamed if it did!). So it seems the niche of boxed lazy arrays is unfilled. And if vector grew a lazy variant it could subsume storablevector and we could consolidate array libraries a little more. It seems a lot of Writer monad type stuff (logging etc.) could be made more efficient with a boxed lazy array builder, at the cost of rougher grained laziness. Does such a thing already exist? I'd check hackage, but it's down... http://www.downforeveryoneorjustme.com/http://hackage.haskell.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Solutions for multi-platform compilation?
We use Jenkins to build our applications. You can have Jenkins slaves for different platforms. We also use cabal-dev to sandbox the builds, separating the environments for different executables. This solution does require one server for every OS you develop for, but I guess you need that anyway, for testing. Erik On Thu, Jul 12, 2012 at 11:43 AM, Ivan Perez wrote: > Hi, > I work developing multi-platform applications in Haskell. This poses > the following problem: I cannot compile binaries for windows from > linux (AFAIK). I "solved" this problem with the following > sledgehammer: I installed windows in a VM, I installed GHC, I > installed all the C/C++ headers & binaries of the libraries that I use > (Gtk, OpenGL, SDL, OpenCV, etc.) their Haskell counterparts, and I > created several scripts that connect to the VM using SSH, push the > changes to the repo, cabal clean & cabal install all my packages in > sequence without me having to even login into the windows machine. I > did this because I was unable to get GHC to run properly in Wine at > that time (over 2 years ago). > > This solution is still unsatisfactory because: > 1) It's slow, even though Windows itself works fine (well, as well as > windows can work, but it runs at a decent spped, I can play games and > all). > 2) When I update a library with lots of dependencies, or GHC itself, > I have to rebuild almost everything. This is particularly painful with > big packages like Gtk, for instance. Because I have to tell cabal > where headers and libraries are located, updating a package is almost > never an automatic process. I haven't always been able to make GHC > "just pick them up" properly with pkg-config. > 3) When I make a change in a library with lots of dependencies, > recompiling all the packages can take several hours. > > I don't think it's a problem with my machine: I'm giving a fair amount > of resources to windows, and I use a 3Ghz quadcore with 8GB of RAM. > > Another relevant fact is: I use this for commercial purposes. I have > customers, each requiring a completely different program, they do not > have infinite budgets and, if there's a problem in the compilation > process and something requires my attention and manual intervention > too often, my salary per hour can easily drop to a ridiculous amount. > If I'm going to redo this, I'd rather just redo it once. > > Any suggestions? How do you solve this kind of problem in your work > environment? > > Cheers, > Ivan > > ___ > 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.org is so fragile
Today I have observed that hackage.haskell.org/ timeout twice (in the noon and in the evening.) What is the problem? Is it that haskell users have increased so that haskell.org is overloaded? That's very good news. I am eager to donate some money if it requires server reinforcement. Sincerely, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's wrong with these foreign calls?
For me it seems like calls to GLFW are normal but when I use indirectly GL
(through GLFW) I see a mess.
How could not they be connected properly?
Please, give me any hint...
I use Ubuntu 12.04 and The Glorious Glasgow Haskell Compilation System,
version 7.4.1
2012/7/11 Андрей Янкин
> Hi all!
>
> I want to use GLFW-b (
> http://hackage.haskell.org/packages/archive/GLFW-b/0.1.0.2/doc/html/Graphics-UI-GLFW.html)
> and I wrote this:
> initWindow = do
> True <- GLFW.initialize
> print =<< GLFW.openGLProfile
> print =<< GLFW.getGlfwVersion
> print =<< *GLFW.getGlVersion*
> print "Trying to open the window"
> result <- GLFW.openWindow GLFW.defaultDisplayOptions
> print result
>
> And got this:
> DefaultProfile
> Version {versionBranch = [2,7,2], versionTags = []}
> Version {versionBranch = [*-1867951663,39789305,39789305*], versionTags
> = []}
> "Trying to open the window"
> False
>
> Why do I always get random numbers as GLVersion?
> How can I detect incompatibility preventing me from opening a window?
>
> Thanks in advance
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad with limited backtracking
On 12/07/2012, Darryn Reid wrote:
> I have formulated a monad to provide
> limited backtracking for implementing a rewrite system. The success case
> works fine, but my intention is that on failure the result should contain the
> list
> of input symbols consumed up to the failure, and it is this part that I would
> like some advice about. Code follows:
> ---
> import Control.Monad
> import Debug.Trace
>
> newtype Rewrite a b = Rewrite { run :: Input a -> Result a b }
>
> data Input a = Input [a]
Why this type? to define other instances?
> data Result a b = Fail [a] | Ok b [a]
> deriving (Eq, Show)
>
> instance (Show a) => Monad (Rewrite a) where
>return y = Rewrite $ \(Input xs) -> Ok y xs
>p >>= f = Rewrite $ \inp ->
> case run p inp of
>Fail xs -> trace ("1.xs=" ++ show xs) $
> Fail xs
>Ok y xs -> case run (f y) (Input xs) of
> Fail xs' -> trace ("2.xs=" ++ show xs) $
> Fail xs
> okay -> okay
>
> instance (Show a) => MonadPlus (Rewrite a) where
>mzero = Rewrite $ \inp -> Fail []
>p `mplus` q = Rewrite $ \inp -> case run p inp of
> Fail _ -> run q inp
> okay -> okay
> (>>=?) ::(Show a) => Rewrite a b -> (b -> Bool) -> Rewrite a b
> p >>=? f = p >>= \y -> guard (f y) >> return y
>
> next :: Rewrite a a
> next = Rewrite $ \(Input xs) -> case xs of
> [] -> Fail []
> (x:xs') -> Ok x xs'
So where are the prior matched symbols? They must be kept somewhere.
Result seems to keep symbols that may be matched in future, not that
have been matched in past. Actually, both must be kept somewhere.
> exactly :: (Show a, Eq a) => [a] -> Rewrite a [a]
> exactly = mapM $ \i -> next >>=? (==i)
> ---
> For example, using ghci:
> *Main> run (exactly [1,2]) (Input [1,2,3,4])
> Ok [1,2] [3,4]
> which is what I intend. However, while the thing correctly reports failure,
> I
> cannot get it to return the list of symbols up to the point of failure:
> *Main> run (exactly [1,2,3]) (Input [1,2,7,4])
> 1.xs=[]
> 2.xs=[4]
> 1.xs=[4]
> 1.xs=[4]
> 2.xs=[7,4]
> 1.xs=[7,4]
> 2.xs=[2,7,4]
> Fail [2,7,4] *I would like Fail [1,2] here instead*
>
> I thank you in advance for any guidance you might offer.
>
> Dr Darryn J Reid.
This works as bidden: http://hpaste.org/71332
BackTrack> :t unBT
unBT :: BackTrack a b -> [a] -> Either [a] ([a], b, [a])
BackTrack> unBT (exactly [1,2]) [1,2,3,4]
Right ([1,2],[1,2],[3,4])
BackTrack> unBT (exactly [1,2,3]) [1,2,7,4]
Left [1,2]
Cheers,
Strake
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] overloading
Hi,I am comparing Haskell's class/instance techniques for overloading with those available Order Sorted Algebra (OSA in CafeOBJ) Using just the basic class/instance mechanism is there any way to avoid the type annotations in the evaluations below?Patclass Location a b where move::a->binstance Location Int Int where move e = e + 3instance Location Float Int where move e = floor(e + 3.1) instance Location [Float] [Int] where move [] = [] move (e:l) = (move e):(move l)instance Location [Int] [Int] where move [] = [] move (e:l) = (move e):(move l)-- evaluations-- testing float-- (move ((7.6::Float))::Int)-- ((move ([21.8,7.4,9.1]::[Float]))::[Int])-- testing integers-- move ((3::Int))::Int-- ((move ([21,7,9]::[Int]))::[Int]) Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy boxed array and builder?
I remember this discussion, lazy vectors would also enable an implementation of bytestring and (maybe) text only with unboxed vectors, unifying it all: type ByteString = Vector Word8 2012/7/12 Evan Laforge > he recent discussion of whether storablevector should be deprecated in > favor of vector reminded me: vector supports storable arrays, but it > doesn't support lazy arrays. While storablevector has lazy arrays and > a builder, it doesn't support boxed types (it would be become misnamed > if it did!). > > So it seems the niche of boxed lazy arrays is unfilled. And if vector > grew a lazy variant it could subsume storablevector and we could > consolidate array libraries a little more. It seems a lot of Writer > monad type stuff (logging etc.) could be made more efficient with a > boxed lazy array builder, at the cost of rougher grained laziness. > > Does such a thing already exist? I'd check hackage, but it's down... > > http://www.downforeveryoneorjustme.com/http://hackage.haskell.org/ > > ___ > 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] Plain lambda inside banana brackets in the arrow notation
On Thu, Jul 05, 2012 at 10:55:07PM +0100, Tsuyoshi Ito wrote: > In a program, I have an arrow MyArr and a combinator called repeat of > the following type: > > repeat :: Int -> (Int -> MyArr e a) -> MyArr e a > > My problem is that the code becomes messy when I use this combinator > inside the arrow notation, and I am looking for a way to write the > code in a more readable way. > [...] > It does not seem possible to use banana brackets here because the type > of the subcomputation does not meet the requirements stated in > http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/arrow-notation.html#id686230. > > How can I use combinators like repeat, which takes a plain function as > an argument, in the arrow notation in a more readable way? Or am I > trying to do an impossible thing? Unfortunately the arrow notation doesn't support this. There's no semantic reason why it wouldn't work with arguments of the form f (a (...(e,t1), ... tn) t) for any functor f, or even g (...(e,t1), ... tn) for any contravariant functor g. The limitation is due to Haskell's structural matching of types. Though one possibility that might get us most of the way there would be to refactor the Arrow class as class PreArrow a where premap :: (b -> b') -> a b' c -> a b c class (Category a, PreArrow a) => Arrow a where arr :: (b -> c) -> a b c arr f = premap f id first :: a b c -> a (b,d) (c,d) instance PreArrow (->) where premap f g = g . f instance PreArrow (Kleisli m) where premap f (Kleisli g) = Kleisli (g . f) instance (PreArrow a, Functor f) => PreArrow (StaticArrow f a) where premap f (StaticArrow g) = StaticArrow (fmap (premap f) g) The PreArrow class would be sufficient for the low-level translation (i.e. excluding if, case and do). You'd need to fiddle with newtypes to use it in your example, though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy boxed array and builder?
On 12 July 2012 15:35, Yves Parès wrote:
> I remember this discussion, lazy vectors would also enable an implementation
> of bytestring and (maybe) text only with unboxed vectors, unifying it all:
> type ByteString = Vector Word8
Yes, I would like to add a lazy storable vector to
vector-bytestring[1] to make the API 100% consistent with bytestring.
Ideally we would have a type like:
data Lazy vector a = Empty | Chuck {-# UNPACK #-} !(vector a) (Lazy vector a)
Unfortunately GHC can't unpack polymorphic fields. The next best thing
is to use a type family which for each type of vector would return its
lazy version (where the vector is unpacked in the cons cell). Then we
would need a class for common operations on those lazy vectors.
Regards,
Bas
[1] http://hackage.haskell.org/package/vector-bytestring
https://github.com/basvandijk/vector-bytestring
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage is down?
http://www.downforeveryoneorjustme.com/hackage.haskell.org -- 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] Hackage is down?
The machine is undergoing disk checks after a hard reboot. Hopefully it will be back online soon.Regards, MalcolmOn Jul 12, 2012, at 03:28 PM, Edward Amsden wrote:http://www.downforeveryoneorjustme.com/hackage.haskell.org -- 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___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's wrong with these foreign calls?
If you load this function in ghci, it behaves absolutely the same way.
How can I create OpenGL window in GLFW-b in ghci?
Prelude> initWindow
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package GLFW-b-0.1.0.2 ... linking ... done.
DefaultProfile
Version {versionBranch = [2,7,2], versionTags = []}
Version {versionBranch = [0,1944,1342031663], versionTags = []}
"Trying to open the window"
False
2012/7/12 Andrey Yankin
> For me it seems like calls to GLFW are normal but when I use indirectly GL
> (through GLFW) I see a mess.
> How could not they be connected properly?
>
> Please, give me any hint...
> I use Ubuntu 12.04 and The Glorious Glasgow Haskell Compilation System,
> version 7.4.1
>
>
> 2012/7/11 Андрей Янкин
>
>> Hi all!
>>
>> I want to use GLFW-b (
>> http://hackage.haskell.org/packages/archive/GLFW-b/0.1.0.2/doc/html/Graphics-UI-GLFW.html)
>> and I wrote this:
>> initWindow = do
>> True <- GLFW.initialize
>> print =<< GLFW.openGLProfile
>> print =<< GLFW.getGlfwVersion
>> print =<< *GLFW.getGlVersion*
>> print "Trying to open the window"
>> result <- GLFW.openWindow GLFW.defaultDisplayOptions
>> print result
>>
>> And got this:
>> DefaultProfile
>> Version {versionBranch = [2,7,2], versionTags = []}
>> Version {versionBranch = [*-1867951663,39789305,39789305*],
>> versionTags = []}
>> "Trying to open the window"
>> False
>>
>> Why do I always get random numbers as GLVersion?
>> How can I detect incompatibility preventing me from opening a window?
>>
>> Thanks in advance
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monads with "The" contexts?
tl;dr: Is there any way to pass the Supercombinator level names (the names in haskell source codes with zero indent) as context to a Monad so that it will read from "The" context? Hello, everyone. I'm thinking of representing our knowledge about our life, the universe and everything as Haskell values. I'd also like to address the uncertainties in our knowledge. The uncertainties are usually continuous (probabilistic distributions) but that's another story. Please forget about it for a while. We learned that List is for nondeterministic context. > earthMass, sunMass, marsMass :: [Double] Let's pretend that there are large uncertainty in our knowledge of the Earth mass. > earthMass = [5.96e24, 5.97e24, 5.98e24] Let's also pretend that we can measure the other bodys' masses only by their ratio to the earth mass, and the measurements have large uncertainties. > sunMass = (*) <$> [2.5e5, 3e5, 4e5] <*> earthMass > marsMass = (*) <$> [0.01, 0.1, 1.0] <*> earthMass Then, how many Mars mass object can we create by taking the sun apart? > sunPerMars :: [Double] > sunPerMars = (/) <$> sunMass <*> marsMass Sadly, this gives too many answers, and some of them are wrong because they assume different Earth mass in calculating Sun and Mars masses, which led to inconsistent calculation. *Main> length $ sunPerMars 81 We had to do this way; > sunMass' e = map (e*) [2.5e5, 3e5, 4e5] > marsMass' e = map (e*) [0.01, 0.1, 1.0] > sunPerMars' :: [Double] > sunPerMars' = do > e <- earthMass > (/) <$> sunMass' e <*> marsMass' e to have correct candidates (with duplicates.) *Main> length $ sunPerMars' 27 The use of (e <- earthMass) seems inevitable for representing that the two Earth masses are taken from the same source of nondeterminism. However, as the chain of the reasoning grows, we can easily imagine the function arguments will grow impractically large. To get the Higgs mass, we will need to feed them all the history of research that led to the measurement of it. There is "the" source of nondeterminism for Earth mass we will always use. Is there a way to represent this? For example, can we define earthMass'' , sunMass'' , marsMass'' all in separate modules, and yet have (length $ sunPerMars'' == 27) ? By the way, *Main> length $ nub $ sort sunPerMars' 16 is not 9. That's another story, I said! Thanks in advance. -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Wed, Jul 11, 2012 at 9:55 PM, Bardur Arantsson wrote:
> On 07/11/2012 05:12 PM, Michael Snoyman wrote:
> >
> > Thanks for the feedback. However, looking at sqlite3.c, I see the
> > necessary #include statements:
> >
> > #include
> > #include
> > #include
> >
> > I'm confident that none of my code is making calls to stat/stat64 via
> > the FFI. In case it makes a difference, this problem also disappears
> > if I compile the library against the system copy of sqlite3 instead of
> > using the C source.
>
> You may need some extra defines, see the comments in "man stat64".
>
> Regards,
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
I've come up with a minimal example that demonstrates this problem. The
crux of the matter is the following C code:
#include
#include
#include
#include
typedef int stat_func(const char*, struct stat*);
stat_func *foo = &stat;
void stat_test(void)
{
struct stat buf;
printf("About to stat-test.c\n");
foo("stat-test.c", &buf);
printf("Done\n");
}
As you can see, all of the include statements are present as necessary. The
code compiles just fine with -Wall -Werror. And when you compile the
Haskell code as well, everything works just fine. But if you follow these
steps, you can reproduce the error I saw:
* Unpack the attached tarball
* `cabal install` in that folder
* `runghc main.hs` from the `exe` folder
On my system at least, I get:
main.hs:
/home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o:
unknown symbol `stat'
main.hs: main.hs: unable to load package `stat-test-0.1.0.0'
One thing I noticed is that I needed to use a function pointer to trigger
the bug. When I called `stat` directly the in stat_test function, gcc
automatically inlined the call, so that the disassessmbled code just showed
a `moveq` (i.e., it's making the system call directly). But using a
function pointer, we're avoiding the inlining. I believe this is why this
issue only came up with the sqlite3 upgrade: previous versions did not use
a function pointer, but rather hard-coded in how to make a stat call.
Does this expose any other possibilities?
Michael
stat-test-0.1.0.0.tar.gz
Description: GNU Zip compressed data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Another topic of ghc --make/ghci differences
1. I wrote this:
-8<- test.hs ---
module Main where
import qualified Graphics.UI.GLFW as GLFW
main = do
True <- GLFW.initialize
print =<< GLFW.openGLProfile
print =<< GLFW.getGlfwVersion
print =<< GLFW.getGlVersion
print "Trying to open the window"
result <- GLFW.openWindow GLFW.defaultDisplayOptions
print result
-8<-
2. Compiled like this: ghc --make -o test test.hs
3. Executed: ./test
DefaultProfile
Version {versionBranch = [2,7,2], versionTags = []}
Version {versionBranch = [0,0,0], versionTags = []}
"Trying to open the window"
True
4. Window appeared.
2'. Executed in GHCI like this:
ghci -fno-ghci-sandbox
Prelude> :l test.hs
Prelude> main
3'. Get (random numbers as GLVersion):
Loading package GLFW-b-0.1.0.2 ... linking ... done.
DefaultProfile
Version {versionBranch = [2,7,2], versionTags = []}
Version {versionBranch = *[34972080,-1323041296,-1334802519]*,
versionTags = []}
"Trying to open the window"
False
4'. Window didn't appear.
What should I do to get GLFW window in ghci too?
What do I do wrong?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Thu, Jul 12, 2012 at 6:29 PM, Michael Snoyman wrote:
>
>
> On Wed, Jul 11, 2012 at 9:55 PM, Bardur Arantsson wrote:
>
>> On 07/11/2012 05:12 PM, Michael Snoyman wrote:
>> >
>> > Thanks for the feedback. However, looking at sqlite3.c, I see the
>> > necessary #include statements:
>> >
>> > #include
>> > #include
>> > #include
>> >
>> > I'm confident that none of my code is making calls to stat/stat64 via
>> > the FFI. In case it makes a difference, this problem also disappears
>> > if I compile the library against the system copy of sqlite3 instead of
>> > using the C source.
>>
>> You may need some extra defines, see the comments in "man stat64".
>>
>> Regards,
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> I've come up with a minimal example that demonstrates this problem. The
> crux of the matter is the following C code:
>
> #include
> #include
> #include
> #include
>
> typedef int stat_func(const char*, struct stat*);
>
> stat_func *foo = &stat;
>
> void stat_test(void)
> {
> struct stat buf;
>
> printf("About to stat-test.c\n");
> foo("stat-test.c", &buf);
> printf("Done\n");
> }
>
> As you can see, all of the include statements are present as necessary.
> The code compiles just fine with -Wall -Werror. And when you compile the
> Haskell code as well, everything works just fine. But if you follow these
> steps, you can reproduce the error I saw:
>
> * Unpack the attached tarball
> * `cabal install` in that folder
> * `runghc main.hs` from the `exe` folder
>
> On my system at least, I get:
>
> main.hs:
> /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o:
> unknown symbol `stat'
> main.hs: main.hs: unable to load package `stat-test-0.1.0.0'
>
> One thing I noticed is that I needed to use a function pointer to trigger
> the bug. When I called `stat` directly the in stat_test function, gcc
> automatically inlined the call, so that the disassessmbled code just showed
> a `moveq` (i.e., it's making the system call directly). But using a
> function pointer, we're avoiding the inlining. I believe this is why this
> issue only came up with the sqlite3 upgrade: previous versions did not use
> a function pointer, but rather hard-coded in how to make a stat call.
>
> Does this expose any other possibilities?
>
> Michael
>
Actually, I just came up with a workaround: declare some local wrappers to
the stat and fstat functions, and use those in place of stat and fstat in
the rest of the code. You can see the change here[1].
Obviously this is a hack, not a real fix. At this point it looks like a GHC
bug to me. Does anything think otherwise? If not, I'll open a ticket.
Michael
[1]
https://github.com/yesodweb/persistent/commit/d7daf0b2fa401fd97ef62e4e74228146d15d8601
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Thu, Jul 12, 2012 at 06:29:41PM +0300, Michael Snoyman wrote:
> I've come up with a minimal example that demonstrates this problem. The
> crux of the matter is the following C code:
>
> #include
> #include
> #include
> #include
>
> typedef int stat_func(const char*, struct stat*);
>
> stat_func *foo = &stat;
>
> void stat_test(void)
> {
> struct stat buf;
>
> printf("About to stat-test.c\n");
> foo("stat-test.c", &buf);
> printf("Done\n");
> }
>
> As you can see, all of the include statements are present as necessary. The
> code compiles just fine with -Wall -Werror. And when you compile the
> Haskell code as well, everything works just fine. But if you follow these
> steps, you can reproduce the error I saw:
>
> * Unpack the attached tarball
> * `cabal install` in that folder
> * `runghc main.hs` from the `exe` folder
>
> On my system at least, I get:
>
> main.hs:
> /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o:
> unknown symbol `stat'
> main.hs: main.hs: unable to load package `stat-test-0.1.0.0'
>
> One thing I noticed is that I needed to use a function pointer to trigger
> the bug. When I called `stat` directly the in stat_test function, gcc
> automatically inlined the call, so that the disassessmbled code just showed
> a `moveq` (i.e., it's making the system call directly). But using a
> function pointer, we're avoiding the inlining. I believe this is why this
> issue only came up with the sqlite3 upgrade: previous versions did not use
> a function pointer, but rather hard-coded in how to make a stat call.
>
> Does this expose any other possibilities?
>
> Michael
Are you trying this on a 32 bit system? And when you compiled that C
program, did you try to add
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
to the compile command? When I define those the resulting object file
from your example correctly references stat64 instead of stat.
pgpTUPJgg88Ia.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Thu, Jul 12, 2012 at 11:07:05AM -0500, Tristan Ravitch wrote: > Are you trying this on a 32 bit system? And when you compiled that C > program, did you try to add > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > > to the compile command? When I define those the resulting object file > from your example correctly references stat64 instead of stat. Er sorry, saw your earlier email now. Could this be a mismatch between how your sqlite.so is compiled and how the cbits in persistent-sqlite are compiled, particularly with largefile support? pgpFocJJrnVmJ.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Thu, Jul 12, 2012 at 7:07 PM, Tristan Ravitch wrote:
> On Thu, Jul 12, 2012 at 06:29:41PM +0300, Michael Snoyman wrote:
> > I've come up with a minimal example that demonstrates this problem. The
> > crux of the matter is the following C code:
> >
> > #include
> > #include
> > #include
> > #include
> >
> > typedef int stat_func(const char*, struct stat*);
> >
> > stat_func *foo = &stat;
> >
> > void stat_test(void)
> > {
> > struct stat buf;
> >
> > printf("About to stat-test.c\n");
> > foo("stat-test.c", &buf);
> > printf("Done\n");
> > }
> >
> > As you can see, all of the include statements are present as necessary.
> The
> > code compiles just fine with -Wall -Werror. And when you compile the
> > Haskell code as well, everything works just fine. But if you follow these
> > steps, you can reproduce the error I saw:
> >
> > * Unpack the attached tarball
> > * `cabal install` in that folder
> > * `runghc main.hs` from the `exe` folder
> >
> > On my system at least, I get:
> >
> > main.hs:
> >
> /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o:
> > unknown symbol `stat'
> > main.hs: main.hs: unable to load package `stat-test-0.1.0.0'
> >
> > One thing I noticed is that I needed to use a function pointer to trigger
> > the bug. When I called `stat` directly the in stat_test function, gcc
> > automatically inlined the call, so that the disassessmbled code just
> showed
> > a `moveq` (i.e., it's making the system call directly). But using a
> > function pointer, we're avoiding the inlining. I believe this is why this
> > issue only came up with the sqlite3 upgrade: previous versions did not
> use
> > a function pointer, but rather hard-coded in how to make a stat call.
> >
> > Does this expose any other possibilities?
> >
> > Michael
>
> Are you trying this on a 32 bit system? And when you compiled that C
> program, did you try to add
>
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
>
> to the compile command? When I define those the resulting object file
> from your example correctly references stat64 instead of stat.
>
I'm compiling on a 64 bit system. If I add those definitions, the program
uses stat64 instead, but the only difference is that runghc now prints:
main.hs:
/home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o:
unknown symbol `stat64'
main.hs: main.hs: unable to load package `stat-test-0.1.0.0'
In other words, it's not the symbol that the object file is referencing
(stat vs stat64) that's the problem: runghc is not able to resolve either
one.
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Jul 12, 2012 7:13 PM, "Tristan Ravitch" wrote: > > On Thu, Jul 12, 2012 at 11:07:05AM -0500, Tristan Ravitch wrote: > > Are you trying this on a 32 bit system? And when you compiled that C > > program, did you try to add > > > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > > > > to the compile command? When I define those the resulting object file > > from your example correctly references stat64 instead of stat. > > Er sorry, saw your earlier email now. Could this be a mismatch > between how your sqlite.so is compiled and how the cbits in > persistent-sqlite are compiled, particularly with largefile support? I don't think so. The test case I put together had nothing to do with sqlite. Also, persistent-sqlite will either use sqlite.so _or_ the included sqlite3.c file (based on a compile-time flag). The former works perfectly, only the latter causes problems. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
On Thu, Jul 12, 2012 at 07:20:39PM +0300, Michael Snoyman wrote: > On Jul 12, 2012 7:13 PM, "Tristan Ravitch" wrote: > > > > On Thu, Jul 12, 2012 at 11:07:05AM -0500, Tristan Ravitch wrote: > > > Are you trying this on a 32 bit system? And when you compiled that C > > > program, did you try to add > > > > > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > > > > > > to the compile command? When I define those the resulting object file > > > from your example correctly references stat64 instead of stat. > > > > Er sorry, saw your earlier email now. Could this be a mismatch > > between how your sqlite.so is compiled and how the cbits in > > persistent-sqlite are compiled, particularly with largefile support? > > I don't think so. The test case I put together had nothing to do with > sqlite. Also, persistent-sqlite will either use sqlite.so _or_ the included > sqlite3.c file (based on a compile-time flag). The former works perfectly, > only the latter causes problems. > > Michael I was looking at the symbols in libc and noticed that it doesn't actually export stat64/stat, so that would explain something at least. I think your idea about the switch to function pointers versus direct calls is probably right - the linker probably does some rewriting of calls to stat into __fxstat and company, but for some reason doesn't handle references to function pointers. I also ran across this stackoverflow post that mentions something similar: http://stackoverflow.com/questions/5478780/c-and-ld-preload-open-and-open64-calls-intercepted-but-not-stat64 So stat64 is actually special and in this libc_nonshared.a library (it is on my system at least). It would be ugly to have to link that manually - not sure what the right answer is, but at least this might explain it. pgpFjqMeqMQZk.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bad interface problem.
On 12-07-11 09:28 PM, Magicloud Magiclouds wrote: And Albert, I did not directly install QuickCheck. It was required by yesod. I can't reproduce that dependency either. Output of "cabal install --dry-run yesod" does not contain QuickCheck or template-haskell. I do not have QuickCheck installed. Resolving dependencies... In order, the following would be installed (use -v for more details): SHA-1.5.1 ansi-terminal-0.5.5 attoparsec-0.10.2.0 base-unicode-symbols-0.2.2.4 base64-bytestring-0.1.2.0 blaze-builder-0.3.1.0 blaze-markup-0.5.1.0 blaze-html-0.5.0.0 byteorder-1.0.3 cereal-0.3.5.2 cpu-0.1.1 css-text-0.1.1 dlist-0.5 data-default-0.4.0 cookie-0.4.0 entropy-0.2.1 enumerator-0.4.19 attoparsec-enumerator-0.3 asn1-data-0.6.1.3 failure-0.2.0.1 fast-logger-0.0.2 hashable-1.1.2.3 case-insensitive-0.4.0.1 http-types-0.6.11 largeword-1.0.2 mime-mail-0.4.1.1 path-pieces-0.1.1 pem-0.1.1 primitive-0.4.1 ranges-0.2.4 email-validate-0.2.8 regex-base-0.93.2 regex-posix-0.95.2 regex-compat-0.95.1 safe-0.3.3 semigroups-0.8.3.2 shakespeare-1.0.0.2 hamlet-1.0.1.4 shakespeare-css-1.0.1.2 shakespeare-i18n-1.0.0.2 shakespeare-js-1.0.0.3 shakespeare-text-1.0.0.2 simple-sendfile-0.2.4 socks-0.4.1 stm-2.4 stringsearch-0.3.6.3 syb-0.3.7 system-filepath-0.4.6 tagged-0.4.2.1 crypto-api-0.10.2 crypto-pubkey-types-0.1.1 certificate-1.2.3 cryptohash-0.7.5 pureMD5-2.1.0.3 pwstore-fast-2.2 skein-0.1.0.7 tagsoup-0.12.6 transformers-base-0.4.1 monad-control-0.3.1.4 lifted-base-0.1.1.1 resourcet-0.3.3.1 unix-compat-0.3.0.1 unordered-containers-0.2.1.0 utf8-string-0.3.7 vault-0.2.0.0 vector-0.9.1 aeson-0.6.0.2 cryptocipher-0.3.5 cprng-aes-0.2.3 clientsession-0.7.5 resource-pool-0.2.1.0 pool-conduit-0.1.0.2 tls-0.9.6 tls-extra-0.4.6 void-0.5.6 conduit-0.4.2 attoparsec-conduit-0.4.0.1 blaze-builder-conduit-0.4.0.2 network-conduit-0.4.0.1 persistent-0.9.0.4 persistent-template-0.9.0.2 wai-1.2.0.3 wai-logger-0.1.4 warp-1.2.2 xml-types-0.3.2 xml-conduit-0.7.0.3 xss-sanitize-0.3.2 yesod-routes-1.0.1.2 zlib-bindings-0.1.0.1 zlib-conduit-0.4.0.2 http-conduit-1.4.1.10 authenticate-1.2.1.1 wai-extra-1.2.0.5 yesod-core-1.0.1.3 yesod-json-1.0.1.0 yesod-persistent-1.0.0.1 yesod-form-1.0.0.4 yesod-auth-1.0.2.1 yesod-1.0.1.6 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Another topic of ghc --make/ghci differences
OK
This is my answer:
http://stackoverflow.com/questions/7867290/freeglut-does-not-work-in-ghci
Linux Nvidia drivers doesn't work with ghci somehow...
2012/7/12 Andrey Yankin
> 1. I wrote this:
> -8<- test.hs ---
> module Main where
> import qualified Graphics.UI.GLFW as GLFW
> main = do
> True <- GLFW.initialize
> print =<< GLFW.openGLProfile
> print =<< GLFW.getGlfwVersion
> print =<< GLFW.getGlVersion
> print "Trying to open the window"
> result <- GLFW.openWindow GLFW.defaultDisplayOptions
> print result
> -8<-
>
> 2. Compiled like this: ghc --make -o test test.hs
> 3. Executed: ./test
> DefaultProfile
> Version {versionBranch = [2,7,2], versionTags = []}
> Version {versionBranch = [0,0,0], versionTags = []}
> "Trying to open the window"
> True
> 4. Window appeared.
>
> 2'. Executed in GHCI like this:
> ghci -fno-ghci-sandbox
> Prelude> :l test.hs
> Prelude> main
> 3'. Get (random numbers as GLVersion):
> Loading package GLFW-b-0.1.0.2 ... linking ... done.
> DefaultProfile
> Version {versionBranch = [2,7,2], versionTags = []}
> Version {versionBranch = *[34972080,-1323041296,-1334802519]*,
> versionTags = []}
> "Trying to open the window"
> False
> 4'. Window didn't appear.
>
> What should I do to get GLFW window in ghci too?
> What do I do wrong?
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monads with "The" contexts?
Hi, Takayuki Muranushi wrote: sunPerMars :: [Double] sunPerMars = (/) <$> sunMass <*> marsMass Sadly, this gives too many answers, and some of them are wrong because they assume different Earth mass in calculating Sun and Mars masses, which led to inconsistent calculation. This might be related to the problem adressed by Sebastian Fischer, Oleg Kiselyov and Chung-chieh Shan in their ICFP 2009 paper on purely functional lazy non-deterministic programming. http://www.cs.rutgers.edu/~ccshan/rational/lazy-nondet.pdf An implementation seems to be available on hackage. http://hackage.haskell.org/package/explicit-sharing Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monads with "The" contexts?
On Thu, Jul 12, 2012 at 11:01 AM, Takayuki Muranushi wrote: > > sunPerMars :: [Double] > > sunPerMars = (/) <$> sunMass <*> marsMass > > Sadly, this gives too many answers, and some of them are wrong because > they assume different Earth mass in calculating Sun and Mars masses, > which led to inconsistent calculation. > I think what you want to do is factor out the Earth's mass, and do your division first: > sunPerMars'' = (/) <$> sunMassCoef <*> marsMassCoef The mass of the earth cancels. That gives a list of length 9, where your approach gave 16 distinct results. But I think that's just floating point rounding noise. Try the same monadic calculation with integers and ratios. The moral? Using numbers in a physics calculation should be your last resort ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org is so fragile
Hi, On 12/07/2012 13:06, Takayuki Muranushi wrote: > Today I have observed that hackage.haskell.org/ timeout twice (in the > noon and in the evening.) > > What is the problem? Is it that haskell users have increased so that > haskell.org is overloaded? That's very good news. > I am eager to donate some money if it requires server reinforcement. The issue is unfortunately more to do with sysadmin resources than server hardware; there's noone with the time to actively manage the server and make sure that it's running well. Any ideas for improving the situation would be gratefully received. Today there were some problems with some processes taking up a lot of resources. One of the problems was the hackage search script, which has been disabled for now. Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org is so fragile
Hello Is there some kind of nagios or similar monitoring software in place? In my experience that really helps when you don't have time to check the servers all the time, especially since it is easy to write small custom plugins for additional checks (e.g. on some of our work servers I have one of those that checks dmesg for kernel oops messages, one to check if the running version of our software is the same as the installed version,...). Matthias Hörmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org is so fragile
On 07/12/2012 11:04 PM, Ganesh Sittampalam wrote: > Hi, > > On 12/07/2012 13:06, Takayuki Muranushi wrote: >> Today I have observed that hackage.haskell.org/ timeout twice (in the >> noon and in the evening.) >> >> What is the problem? Is it that haskell users have increased so that >> haskell.org is overloaded? That's very good news. >> I am eager to donate some money if it requires server reinforcement. > > The issue is unfortunately more to do with sysadmin resources than > server hardware; there's noone with the time to actively manage the > server and make sure that it's running well. Any ideas for improving the > situation would be gratefully received. > > Today there were some problems with some processes taking up a lot of > resources. One of the problems was the hackage search script, which has > been disabled for now. > Since I don't have insight into the "inner sanctum" (aka. "service/server setup") this may be way off base, but how about adding a Varnish instance in front of haskell.org and its various subdomains? It could cache everything for 5 minutes (unconditional) and reduce load by ridiculous amounts. Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org is so fragile
Hello, > The issue is unfortunately more to do with sysadmin resources than > server hardware; there's noone with the time to actively manage the > server and make sure that it's running well. Any ideas for improving the > situation would be gratefully received. I don't know about the current architecture of Hackage. But what about this: the main server concentrates on registration/uploading and mirrors serve queries/downloading. Yesterday some Japanese Haskellers used a mirror server: http://hackage.haskell.biz/ --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monads with "The" contexts?
Tillmann Rendel has correctly noted that the source of the problem is the correlation among the random variables. Specifically, our measurement of Sun's mass and of Mars mass used the same rather than independently drawn samples of the Earth mass. Sharing (which supports what Functional-Logic programming calls ``call-time choice'') is indeed the solution. Sharing has very clear physical intuition: it corresponds to the collapse of the wave function. Incidentally, a better reference than our ICFP09 paper is the greatly expanded JFP paper http://okmij.org/ftp/Computation/monads.html#lazy-sharing-nondet You would also need a generalization of sharing -- memoization -- to build stochastic functions. The emphasis is on _function_: when applied to a value, the function may give an arbitrary sample from a distribution. However, when applied to the same value again, the function should return the same sample. The general memo combinator is implemented in Hansei and is used all the time. The following article talks about stochastic functions (and correlated variables): http://okmij.org/ftp/kakuritu/index.html#all-different and the following two articles show just two examples of using memo: http://okmij.org/ftp/kakuritu/index.html#noisy-or http://okmij.org/ftp/kakuritu/index.html#colored-balls The noisy-or example is quite close to your problem. It deals with the inference in causal graphs (DAG): finding out the distribution of conclusions from the distribution of causes (perhaps given measurements of some other conclusions). Since a cause may contribute to several conclusions, we have to mind sharing. Since the code works by back-propagation (so we don't have to sample causes that don't contribute to the conclusions of interest), we have to use memoization (actually, memoization of recursively defined functions). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
