[Haskell] ANNOUNCE: Release of 'randproc' package v0.1
Announcing the release of v0.1 of 'randproc', a library for working with random processes. http://www.haskell.org/haskellwiki/Random_Processes ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: release v0.2 of RandProc library
v0.2 of the `RandProc` library has been released to HackageDB. http://hackage.haskell.org/package/randproc Changes in this release: * Improved several severe performance bottlenecks. (The `goodDie` space can now actually be checked, without exhausting memory/time.) * Cleaned up the code, as per `hlint` suggestions. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: RandProc v0.4 released.
v0.4 of `RandProc` has just been posted to Hackage: http://hackage.haskell.org/package/randproc In this release: * Examples of using the `RandProc` library to work problems from `Random Processes` text have been added. * `README` file has been fleshed out a bit. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: broker-haskell v0.1
The initial release of broker-haskell, a Haskell binding to Broker (libbroker),
the messaging library for Bro, a network security tool.
Provides:
- Language.Broker
After downloading/extracting compressed tarball:
davids-air-2:broker-haskell-0.1.0.0 dbanas$ cabal configure --prefix=$HOME
--user --enable-tests
Resolving dependencies...
Configuring broker-haskell-0.1.0.0...
davids-air-2:broker-haskell-0.1.0.0 dbanas$ cabal build
Building broker-haskell-0.1.0.0...
Preprocessing library broker-haskell-0.1.0.0...
[1 of 1] Compiling Language.Broker ( dist/build/Language/Broker.hs,
dist/build/Language/Broker.o )
{Some warnings omitted.}
In-place registering broker-haskell-0.1.0.0...
Preprocessing test suite 'tests' for broker-haskell-0.1.0.0...
[1 of 1] Compiling Main ( test.hs,
dist/build/tests/tests-tmp/Main.o )
{Some warnings omitted.}
Linking dist/build/tests/tests ...
davids-air-2:broker-haskell-0.1.0.0 dbanas$ cabal test
Preprocessing library broker-haskell-0.1.0.0...
In-place registering broker-haskell-0.1.0.0...
Preprocessing test suite 'tests' for broker-haskell-0.1.0.0...
Running 1 test suites...
Test suite tests: RUNNING...
Test suite tests: PASS
Test suite logged to: dist/test/broker-haskell-0.1.0.0-tests.log
1 of 1 test suites (1 of 1 test cases) passed.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Redundant entries in .cabal file?
Hi all, Does anyone know why I’m getting redundant entries in my ‘cabal init’ generated .cabal file: library exposed-modules: Language.Broker, Language.Broker ? Is it because I’m using a *.hsc file, as my source, and cabal is finding both files: Broker.hsc, and Broker.hs in the Language directory? Thanks, -db ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] libiconv trouble?
Anyone else hit this, after updating to the new Haskell Platform? Davids-MacBook-Air-2:tmp dbanas$ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help command line: can't load .so/.DLL for: libiconv.dylib (dlopen(libiconv.dylib, 5): image not found) Thanks, -db ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] libiconv trouble?
No, but I did set two other, related environment variables, very recently: export LIBRARY_PATH=$HOME/anaconda/lib:$LIBRARY_PATH export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib:$HOME/anaconda/lib:/usr/local/bro/lib:$DYLD_FALLBACK_LIBRARY_PATH and one of them must have been the problem, because when I comment out the two lines, above, in my .bash_profile file, ghci works fine. Thanks! On Aug 15, 2015, at 1:34 PM, Brandon Allbery allber...@gmail.com wrote: On Sat, Aug 15, 2015 at 4:26 PM, David Banas capn.fre...@gmail.com wrote: Davids-MacBook-Air-2:tmp dbanas$ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help command line: can't load .so/.DLL for: libiconv.dylib (dlopen(libiconv.dylib, 5): image not found) This seems odd. Did you set DYLD_LIBRARY_PATH in the environment? /usr/lib/libiconv.dylib should be present on all versions of OS X, except possibly (I can't check) the El Capitan public beta. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ETA on 7.10.3?
Hi, Does anyone have an ETA for ghc v7.10.3? (I'm trying to decide between waiting and backing up to 7.8.2, for a particular project.) Thanks, -db ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] ETA on 7.10.3?
Hi Ben, Thanks for your reply. My problem is the project I’m currently working on is dependent upon HERMIT, which doesn’t play well with 7.10.2, as per: https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767 (The nature of that comment caused me to think that 7.10.3 was in play.) Thanks, -db On Sep 2, 2015, at 12:05 AM, Ben Gamari <b...@smart-cactus.org> wrote: > David Banas <capn.fre...@gmail.com> writes: > >> Hi, >> >> Does anyone have an ETA for ghc v7.10.3? >> (I'm trying to decide between waiting and backing up to 7.8.2, for a >> particular project.) >> > Currently there are no plans to do a 7.10.3 release. 7.10.2 does has a > few issues, but none of them are critical regressions but none of them > appear critical enough to burn maintenance time on. > > Of course, we are willing to reevaluate in the event that new issues > arise. What problems with 7.10.2 are you struggling with? > > Cheers, > > - Ben ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell-cafe] Trouble with `foldl` in composition chain.
When profiling this code: consolidateRPR :: [Sample] - [Sample] smplUnionRecursRev :: [Sample] - Sample - [Sample] sortSamps :: [Sample] - [Sample] smplSetUnion :: [Sample] - [Sample] smplSetUnion = consolidateRPR . (foldl smplUnionRecursRev []) . sortSamps I'm getting this: smplSetUnion Data.RandProc 1038 32794 0.70.276.9 72.6 consolidateRPRData.RandProc 1041 32794 0.00.0 8.2 11.8 smplUnionRecursRev Data.RandProc 1040 918112 8.85.6 8.85.6 sortSamps Data.RandProc 1039 1081514 21.1 55.059.2 55.0 I'm confused as to why `sortSamps` is being called so many times. I would expect it to be called 32794 times, just like `consolidateRPR`. It's as if having a `foldl` to the left of `sortSamps` in the composition chain is causing it to execute more than once, per call of `smplSetUnion`, but I wouldn't expect that. This doesn't change anything: smplSetUnion = consolidateRPR . (\ss - foldl smplUnionRecursRev [] ss) . sortSamps (I thought it might explicitly close the `foldl`.) In fact, even this: smplSetUnion ss = consolidateRPR $ foldl smplUnionRecursRev [] ss' where ss' = sortSamps ss doesn't change anything. `sortSamps` still gets entered 1081514 times! Can anyone help clear up this newbie's fog? Thanks, in advance! -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-Cafe] Constructive Probability Theory and RandProc's σ-algebras
Hi Edward,
Thanks for your interest in `RandProc`.
I'm very interested in continuing this conversation with you, but I think I'd
better read the papers you recommend, below first, so that I can do so
intelligently. ;-)
In the mean time, I do have these rather imprecise thoughts:
(Please, see in-line below.)
Looking forward to much more conversation with you (and others),
-db
On Jul 3, 2011, at 9:35 AM, Edward Kmett wrote:
On Sun, Jul 3, 2011 at 11:05 AM, David Banas dba...@banasfamily.net wrote:
v0.4 of `RandProc` has just been posted to Hackage:
http://hackage.haskell.org/package/randproc
[NB: I transfered this discussion from haskell to haskell-cafe, and started
another thread]
I have been spending some time exploring constructive probability theory in
Haskell, and I have a couple of observations about working with random
processes in a constructive setting:
Necessarily because you are working in Haskell, a constructive setting, your
σ-algebras can't be actual σ-algebras! =/
Yes, I realize I've taken some rather arrogant liberty in calling my function
`checkSigma`, for instance.
Notably, they aren't closed under countable union/intersection/complement,
but merely finite union/intersection/complement, and Gray and Davisson's
horrified objections from the bottom of page 39 on Random Processes applies:
If a class of sets is only a field rather than a σ-field, that is, if it
satisfies only (3.1) and (3.2), then there is no guarantee that the class
will contain all limits of sets. Hence, for example knowing that a class of
sets contains all half-open intervals of the form (a,b] for a and b finite
does not ensure that it will also contain points or singleton sets! In fact,
it is straightforward to show that the collection of all such half-open
intervals together with the complements of such sets and all finite unions of
the intervals and complements forms a field. The singleton sets, however, are
not in the field. (See exercise 3.4)
Thus if we tried to construct a probability theory based on only a field, we
might have probabilites defined for events such as (a,b) meaning the output
voltage of a measurement is between a and b yet not have probabilities
defined for a singleton set {a} meaning the output voltage is exactly a. By
requiring that the event space be a σ-field instead of only a field, we are
assured that all such limits are indeed events.
So, my hope was that, by providing for a `Point` sample, in addition to
`Range`, I'd gotten around this issue, although I confess that I really haven't
thought it through.
This limitation, while from some perspective annoying is intrinsic to
tackling the problem intuitionistically. Practically, this means you need to
be careful when rederiving most of the later results, because you are limited
to what you can prove in a constructive measure theory.
In particular the approaches of YK Chan, Brian Weatherson, and Glenn Shafer
to intuitionistic probability theory are probably appropriate reading.
I will read these. Thanks for the references!
Personally, I don't think this is all that bad, we get some nice properties
by being in a constructive setting. Weatherson noted that your measure
becomes additive without problems from Dutch book arguments in an
intuitionistic setting, because P(A v not A) is not necessarily 1!
I'm enforcing this condition in my `checkProbMeas` function; should I relax
this?
You may recall that recall that additivity would imply that P(A v B) = P(A) +
P(B), given that A and B are disjoint, but that it tends to fall apart in
classical probability theory.
I've been assuming the above true, in general. I didn't realize that it was
fragile. Could you point me to a reference on this, please?
Intuitionistically, however, this is fine. That is to say that if you placed
bets that payed out with market rate interest at a rational booking agent on
both whether P = NP and P /= NP, it isn't just as good as having placed a bet
on truth, because intuitionistically it is possible that neither of those
bets may ever pay out, but in a classical setting P (P = NP v P /= NP) =
P(True) = 1, so we lose additivity to gain the excluded middle.
I'm sorry, but I'm lost here. Is there a simple example, which illustrates this?
The cost of additivity is giving up or refining a lot of results from that
text that talk about the limit of a random process. That and that the
σ-fields in question are mere fields. ;)
So, as I was writing this module and realizing that I wasn't really testing
sigma fields, but only fields, I asked myself, How might Haskell be used to
prove, in a finite amount of time, some property of a countably infinite set of
samples? Obviously, it can't be done in the straight forward fashion, but is
there some way to specify properties of the countably infinite set, as opposed
to the actual set itself, which might make
[Haskell-cafe] Getting segmentation fault when profiling, despite `-K100M'.
Hi all,
I'm trying to profile a mixed language program, in which Haskell is NOT
the top layer and does not contain the `main' function. (C is/does.)
Is this effort doomed to fail?
I'm getting a segmentation fault, as soon as the first Haskell function
is called, despite having included `-K100M' in my list of +RTS args:
19 int argc = 5;
20 char* argv[] = {ghcDll,
21 +RTS,
22 -hc,
23 -p,
24 -K100M,
25 NULL}; // argv must end with NULL
26
27 // Initialize Haskell runtime
28 char** args = argv;
29 hs_init(argc, args);
Using gdb to trace through the C-code, up until the first call to
Haskell, I get to here:
64 // Call the Haskell function.
65 res = amiInit(
66 impulse_matrix,
67 row_size,
Here's the beginning of `amiInit':
41 -- Our Haskell implementation of `AMI_Init'.
42 amiInit :: Ptr CDouble - CInt - CInt - CDouble - CDouble -
43CString - Ptr CString - Ptr (StablePtr AmiModel) - Ptr
CString - IO Int
44 amiInit impulse_matrix row_size aggressors sample_interval bit_time
45 ami_parameters_in ami_parameters_out ami_memory_handle
msgHndl
46 | impulse_matrix == nullPtr = return 0
47 | otherwise = do
48 putStrLn I'm here.
I never see I'm here. printed to my console, before I get the
segmentation fault.
Any thoughts?
Thanks,
-db
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Failed link to mixed-language shared object.
Hi all, Does this trigger recollection in anyone: dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make ghc -dynamic -o ami_test -L. -lami ami_test.o ./libami.so: undefined reference to `__stginit_haskell98_MarshalArray_' ./libami.so: undefined reference to `__stginit_haskell98_MarshalError_' collect2: ld returned 1 exit status make: *** [ami_test] Error 1 dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ ? Know what I need to do? Thanks, -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Failed link to mixed-language shared object.
On Thu, 2011-08-18 at 20:32 -0700, David Banas wrote:
Hi all,
Does this trigger recollection in anyone:
dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make
ghc -dynamic -o ami_test -L. -lami ami_test.o
./libami.so: undefined reference to `__stginit_haskell98_MarshalArray_'
./libami.so: undefined reference to `__stginit_haskell98_MarshalError_'
collect2: ld returned 1 exit status
make: *** [ami_test] Error 1
dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$
?
Know what I need to do?
Thanks,
-db
So, I was able to make my link errors go away, by adding `-shared' to my
command line:
dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make
ghc -no-hs-main -shared -dynamic -o ami_test -L. -lami ami_test.o
However, when I try to execute the resultant program, I get a
segmentation fault:
dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ ./ami_test test.ami
Segmentation fault
Tracing this shows that the `main' pointer of the program appears to be
NULL:
dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ gdb --args ./ami_test
test.ami
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols
from /home/dbanas/prj/haskell/AMIParse/trunk/ami_test...done.
(gdb) l
2 #include stdlib.h
3 #include string.h
4 //#include HsFFI.h
5 #include ami_model.h
6
7 #define DEF_AMI_FILE test.ami
8 #define VEC_SIZE 8
9 #define MAX_LINE_LEN 256
10
11 int main(int argc, char *argv[]) {
(gdb) b 11
Breakpoint 1 at 0x87d: file ami_test.c, line 11.
(gdb) run
Starting program: /home/dbanas/prj/haskell/AMIParse/trunk/ami_test
test.ami
Program received signal SIGSEGV, Segmentation fault.
0x0002 in ?? ()
I assume that's because of the `-shared' flag.
Any thoughts?
Thanks,
-db
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Failed link to mixed-language shared object
ghc -dynamic -o ami_test -L. -lami ami_test.o
./libami.so: undefined reference to `__stginit_haskell98_MarshalArray_'
./libami.so: undefined reference to `__stginit_haskell98_MarshalError_'
collect2: ld returned 1 exit status
I was able to solve this by changing these lines:
import MarshalArray
import MarshalError
to read:
import Foreign.Marshal.Array
import Foreign.Marshal.Error
I don't understand why this worked, since the available symbols in the 2
respective libraries appear totally similar:
dbanas@dbanas-eeepc:/usr/lib/ghc-6.12.3$ nm -g
haskell98-1.0.1.1/libHShaskell98-1.0.1.1.a | grep 'MarshalArray'
MarshalArray__1.o:
0030 T __stginit_haskell98_MarshalArray
T __stginit_haskell98_MarshalArray_
dbanas@dbanas-eeepc:/usr/lib/ghc-6.12.3$ nm -g -D
haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so | grep 'MarshalArray'
2b68 T __stginit_haskell98_MarshalArray
2b24 T __stginit_haskell98_MarshalArray_dyn
dbanas@dbanas-eeepc:/usr/lib/ghc-6.12.3$ nm -g base-4.2.0.2/libHSbase-4.2.0.2.a
| grep '__stginit_.*Foreign.*Marshal.*Array'
006c T __stginit_base_ForeignziMarshalziArray
T __stginit_base_ForeignziMarshalziArray_
{Some output omitted.}
dbanas@dbanas-eeepc:/usr/lib/ghc-6.12.3$ nm -g -D
base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so | grep
'__stginit_.*Foreign.*Marshal.*Array'
003dc8cc T __stginit_base_ForeignziMarshalziArray
003dc834 T __stginit_base_ForeignziMarshalziArray_dyn
Can anyone shed some light on this?
Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make shared library - questions
I'm trying to compile shared library. This library will use as part of plugin for some program. If I compile library with option -dynamic my library has links for HS libraries like libHSbase-4.2.0.2-ghc6.12.3.so and so on. But program has crashed constantly. Is it possible to make shared library without -dynamic flag? I want to try to make library without dependencies. I struggled with this, too. Here's my makefile, which is now working: 1 GCC = gcc 2 CFLAGS += -I/usr/lib/ghc-6.12.3/include/ -g -fPIC 3 4 HC = ghc 5 HC_OPTS = -cpp $(EXTRA_HC_OPTS) 6 EXTRA_HC_OPTS = -package parsec 7 HC_LOPTS = -no-hs-main -shared -package parsec 8 #GHCOPTS := -prof -auto-all -caf-all 9 10 HSRCS = AMIParse.hs AMIModel.hs ApplicativeParsec.hs 11 CSRCS = ami_model.c ami_test.c 12 SRCS = $(HSRCS) $(CSRCS) 13 OBJS = AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o 14 15 .SUFFIXES : .o .hs .hi .lhs .hc .s .c 16 .PHONY : all depend rebuild clean 17 18 all: ami_test 19 20 ami_test: ami_test.o libami.so 21 $(HC) -dynamic -o $@ -L. -lami ami_test.o 22 23 libami.so : $(OBJS) 24 rm -f $@ 25 $(HC) -o $@ $(HC_LOPTS) $^ 26 27 depend: 28 $(HC) -M $(HC_OPTS) $(HSRCS) 29 30 rebuild: 31 $(MAKE) clean 32 $(MAKE) all 33 34 clean: 35 rm -f *.hi *.o *.out ami_test *.so 36 37 # Standard suffix rules 38 .o.hi: 39 @: 40 41 .lhs.o: 42 $(HC) -c $ $(HC_OPTS) 43 44 .hs.o: 45 $(HC) -c $ $(HC_OPTS) 46 47 .o-boot.hi-boot: 48 @: 49 50 .lhs-boot.o-boot: 51 $(HC) -c $ $(HC_OPTS) 52 53 .hs-boot.o-boot: 54 $(HC) -c $ $(HC_OPTS) 55 56 # Individual cases 57 AMIModel_stub.o: AMIModel.hs 58 $(HC) -c $ $(HC_OPTS) 59 60 # DO NOT DELETE: Beginning of Haskell dependencies 61 ApplicativeParsec.o : ApplicativeParsec.hs 62 AMIParse.o : AMIParse.hs 63 AMIParse.o : ApplicativeParsec.hi 64 AMIModel.o : AMIModel.hs 65 AMIModel.o : AMIParse.hi 66 # DO NOT DELETE: End of Haskell dependencies Good luck! -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
Hi all, I'm trying to build a shared, dynamic library for use with a C program. I'm getting an `undefined symbol' error, when I try to run that C program, and was hoping that the last line in the output, below, might mean something to someone. I include the entire output of a `make rebuild' command, below, hoping that, maybe, I just have my command line options a little wrong. Thanks! -db dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make rebuild make clean make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' rm -f *.hi *.o *.out ami_test *.so make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' make all make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_test.o ami_test.c gcc -rdynamic -o ami_test ami_test.o -ldl ghc -c ApplicativeParsec.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c AMIParse.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c ExmplUsrModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c AMIModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_model.o ami_model.c rm -f libami.so ghc -o libami.so -shared -dynamic -package parsec-3.1.1 -package dsp AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o ExmplUsrModel.o make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ ./ami_test test.ami /usr/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so: undefined symbol: stg_newByteArrayzh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for help: Recompile of ghc producing ...-ghc7.4.2.sos, which break project builds.
I am able to fix my build problem, by creating a link to *
libHSrts-ghc7.4.2.so, *named *libHSrts.so*:
dbanas@dbanas-lap:~/prj/AMI-Tool$ ll /usr/lib/ghc-7.4.2/libHSrts*
-rw-r--r-- 1 root root 980950 Apr 23 20:08 /usr/lib/ghc-7.4.2/libHSrts.a
{snip}
-rwxr-xr-x 1 root root 429218 Apr 23 20:08
/usr/lib/ghc-7.4.2/libHSrts-ghc7.4.2.so*
{snip}
lrwxrwxrwx 1 root root 20 Apr 27 08:20 /usr/lib/ghc-7.4.2/*libHSrts.so*-
libHSrts-ghc7.4.2.so*
{snip}
dbanas@dbanas-lap:~/prj/AMI-Tool$ make
rm -f libami.so
ghc -o libami.so -shared -dynamic -package parsec -lHSrts -lm -lffi -lrt
AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
dbanas@dbanas-lap:~/prj/AMI-Tool$
However, I'm a little confused as to why the -package parsec isn't
triggering the same issue, since the parsec dynamic libraries were given
the same -ghc7.4.2 suffix:
dbanas@dbanas-lap:~/prj/AMI-Tool$ ll ~/.cabal/lib/parsec-3.1.3/ghc-7.4.2/
total 5816
{snip}
-rw-r--r-- 1 dbanas dbanas 1006668 Apr 24 16:37 HSparsec-3.1.3.o
-rw-r--r-- 1 dbanas dbanas 1340698 Apr 24 16:37 libHSparsec-3.1.3.a
-rwxr-xr-x 1 dbanas dbanas 1061317 Apr 24 16:37 libHSparsec-3.1.3*-ghc7.4.2*
.so*
{snip}
*Any thoughts?*
Thanks,
-db
On Saturday, April 27, 2013 6:37:43 AM UTC-7, David Banas wrote:
Recently, I had to recompile ghc, in order to get the -dyn versions of
the standard libraries installed. (The standard Ubuntu 12.10 64-bit Linux
distribution doesn't include them in its haskell-platform package, and
you can't upgrade base using the normal cabal iinstall approach, from
what I understand.)
When I did this, the -dyn versions of the standard libraries were, in
fact, installed. However, they were given names with a -ghc7.4.2.so
suffix. And this is causing the build of a previously working project to
break, thusly:
ghc -o libami.so -shared -dynamic -package parsec *-lHSrts* -lm -lffi
-lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
/usr/bin/ld: /usr/lib/ghc-7.4.2/*libHSrts.a*(RtsAPI.o): relocation
R_X86_64_32S against `ghczmprim_GHCziTypes_Czh_con_info' can not be used
when making a shared object; recompile with -fPIC
The problem is this: the linker is picking up the *.a version of the *
HSrts* library, instead of the *.so version, which is what it really
needs. And the reason it's doing this is the *.so version has been given
a -ghc7.4.2 suffix:
dbanas@dbanas-lap:~/prj/AMI-Tool$ l /usr/lib/ghc-7.4.2/libHSrts*
/usr/lib/ghc-7.4.2/libHSrts.a
{snip}
/usr/lib/ghc-7.4.2/libHSrts*-ghc7.4.2*.so*
{snip}
So, it seems to me that I need to either:
1. Tell the linker about the possibility of a -ghc7.4.2 file name
suffix, or
2. rebuild my *.sos without that suffix.
*Can anyone tell me:*
- *How to accomplish either #1 or #2, above?*
- *Which one is the preferred solution to the problem?*
- *Am I completely off in the weeds?*
- *If so, what should I really be doing, in order to fix this issue?*
Thanks!
-db
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question about Newtype op() function arguments.
Hi All, Referring to the following, which is taken from the *Control.Newtype *documentation page: op :: Newtypehttp://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/Control-Newtype.html#t:Newtype n o = (o - n) - n - oSourcehttp://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/src/Control-Newtype.html#op This function serves two purposes: 1. Giving you the unpack of a newtype without you needing to remember the name. 2. Showing that the first parameter is *completely ignored* on the value level, meaning the only reason you pass in the constructor is to provide type information. Typeclasses sure are neat. As point #2, above, emphasizes, the only purpose for the first argument to the function (i.e. - the constructor (o - n)) is to specify the type of 'n'. However, being a *newtype*, 'n' can have only one constructor. So, why is it necessary to pass in the constructor to this function, when we're already passing in 'n'? Thanks, -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about Newtype op() function arguments.
Ah, so is the idea, then, to use *op()* when `n` wasn't actually constructed formally, but rather assembled by the user, so as to match the type of the accessor function normally supplied as the argument to the constructor? On 6/7/2013 4:51 PM, Tom Ellis wrote: On Fri, Jun 07, 2013 at 04:05:09PM -0400, Joe Q wrote: The phantom parameter solves the same problem as scoped type variables. Granted, if you find yourself in that kind of polymorphic soup you have deeper problems... I don't understand this. Scoped type variables are used when you want to use a type variable from the top level within the body of a function. If you use op and specify a particular constructor then you don't have a variable but a concrete instance of a type. But maybe I'm missing some more powerful way this can be used ... Tom You can use scoped type variables to correct an ambiguous type error. You can think of op as a variation on asTypeOf, as documented here on http://www.haskell.org/haskellwiki/Scoped_type_variables#Avoiding_Scoped_Type_Variables . If I tried to come up with an example that's specific to op, it would only be horribly contrived. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are field selectors functions?
Wouldn't the implementation hiding feature of the *newtype *idiom be
broken, if field selectors were not first class functions? For instance,
the following code (taken shamelessly from Ch. 10 of *Real World Haskell*):
module Parse (
runParser
) where
data ParseState = ParseState {
string :: String
} deriving (Show)
newtype Parser a = Parser {
runParser :: ParseState - Either String (a, ParseState)
}
has the attractive feature of hiding the internal implementation of
the *ParseState
*and *Parser *types from the user, preventing him from, for instance,
pattern matching on either and thus writing code, which may break when we
change the implementation. I believe this is only possible, because
the *runParser
*accessor is exportable as a first class function.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Trouble installing haskeline: ExitFailure 139
Has anyone else hit an unexplained *ExitFailure 139* when trying to install the *haskeline* package? Thanks, -db dbanas@dbanas-lap:~/prj$ cabal install -v haskeline Reading available packages... Choosing modular solver. Resolving dependencies... Extracting /home/dbanas/.cabal/packages/ hackage.haskell.org/haskeline/0.7.0.3/haskeline-0.7.0.3.tar.gz to /tmp/haskeline-0.7.0.3-16574... creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup /usr/local/bin/ghc --make /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs -o /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup -odir /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -hidir /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -i -i/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3 -package Cabal-1.16.0 [1 of 1] Compiling Main ( /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs, /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/Main.o ) Linking /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup ... /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup configure --verbose=2 --ghc --prefix=/home/dbanas/.cabal --user --flags=terminfo --flags=-libiconv --flags=-legacy-encoding --constraint=unix ==2.6.0.1 --constraint=transformers ==0.3.0.0 --constraint=terminfo ==0.3.2.5 --constraint=filepath ==1.3.0.1 --constraint=directory ==1.2.0.1 --constraint=containers ==0.5.0.0 --constraint=bytestring ==0.10.0.2 --constraint=base ==4.6.0.1 --disable-tests --disable-benchmarks World file is already up to date. cabal: Error: some packages failed to install: haskeline-0.7.0.3 failed during the configure step. The exception was: ExitFailure 139 dbanas@dbanas-lap:~/prj$ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
TH Show instance not working.
Hi all, Does anyone know why this code: module Language.P4.UtilTest where import Language.P4.Util (mkShow) data Dummy = BogusChar | Nonsense Int $(mkShow ''Dummy) is producing this error: Davids-Air-2:P4 dbanas$ stack ghc -- UtilTest.hs -ddump-splices [1 of 1] Compiling Language.P4.UtilTest ( UtilTest.hs, UtilTest.o ) UtilTest.hs:24:3-16: Splicing declarations mkShow ''Dummy ==> instance Show Dummy where show (Bogus x) = show x show (Nonsense x) = show x UtilTest.hs:24:3: error: Conflicting definitions for ‘show’ Bound at: UtilTest.hs:24:3-16 UtilTest.hs:24:3-16 | 24 | $(mkShow ''Dummy) | ^^ ? The TH splice expansion looks correct to me. If I comment out the second constructor (Nonsense Int), the code compiles without error. Thanks, -db ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: TH Show instance not working.
Yep, that was it. Thanks, Li-yao! -db > On Aug 20, 2017, at 12:29 AM, Li-yao Xia <lys...@gmail.com> wrote: > > Hi David, > > mkShow is probably making two separate declarations for "show" ([FunD "show" > _, FunD "show" _]) instead of one declaration with two clauses ([FunD "show" > [Clause ..., Clause ...]]). > Both pretty-print to the same text, but only the second one is actually > valid. When there is only one constructor, both alternatives end up the same. > > Li-yao > > On 08/20/2017 02:16 AM, David Banas wrote: >> Hi all, >> >> Does anyone know why this code: >> >> module Language.P4.UtilTest where >> >> import Language.P4.Util (mkShow) >> >> data Dummy = BogusChar >>| Nonsense Int >> >> $(mkShow ''Dummy) >> >> is producing this error: >> >> Davids-Air-2:P4 dbanas$ stack ghc -- UtilTest.hs -ddump-splices >> [1 of 1] Compiling Language.P4.UtilTest ( UtilTest.hs, UtilTest.o ) >> UtilTest.hs:24:3-16: Splicing declarations >> mkShow ''Dummy >> ==> >> instance Show Dummy where >> show (Bogus x) = show x >> show (Nonsense x) = show x >> >> UtilTest.hs:24:3: error: >> Conflicting definitions for ‘show’ >> Bound at: UtilTest.hs:24:3-16 >> UtilTest.hs:24:3-16 >>| >> 24 | $(mkShow ''Dummy) >>| ^^ >> >> ? >> >> The TH splice expansion looks correct to me. >> If I comment out the second constructor (Nonsense Int), the code compiles >> without error. >> >> Thanks, >> -db >> >> >> >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
