Re: regression in ghc / cabal integration in 9.2.1

[Albert Y. C. Lai]

On 2021-10-30 3:43 p.m., Brandon Allbery wrote:

Wasn't there specifically a new cabal version released to deal with
9.2.1? 3.4.1.0 / 3.6.2.0?


There is a double fault here.

Firstly yes, one should use a newer version of cabal-install that is 
known to support GHC 9.2.


So, 3.6.2.0 it is! But GHC 9.2.1 will also play a role...

$ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.1

$ cabal install --lib vector
Resolving dependencies...
Build profile: -w ghc-9.2.1 -O1
In order, the following will be built (use -v for more details):
 - primitive-0.7.3.0 (lib) (requires download & build)
 - vector-0.12.3.1 (lib) (requires download & build)
[... success ...]

$ cat .ghc/x86_64-linux-9.2.1/environments/default
clear-package-db
global-package-db
package-db /home/trebla/.cabal/store/ghc-9.2.1/package.db
package-id ghc-9.2.1
package-id bytestring-0.11.1.0
package-id unix-2.7.2.2
package-id base-4.16.0.0
package-id time-1.11.1.1
package-id hpc-0.6.1.0
package-id filepath-1.4.2.1
package-id process-1.6.13.2
package-id array-0.5.4.0
package-id integer-gmp-1.1
package-id containers-0.6.5.1
package-id ghc-boot-9.2.1
package-id binary-0.8.9.0
package-id ghc-prim-0.8.0
package-id ghci-9.2.1
package-id rts
package-id terminfo-0.4.1.5
package-id transformers-0.5.6.2
package-id deepseq-1.4.6.0
package-id ghc-boot-th-9.2.1
package-id pretty-1.1.3.6
package-id template-haskell-2.18.0.0
package-id directory-1.3.6.2
package-id text-1.2.5.0
package-id 
vector-0.12.3.1-0ee0e7c1da5d41be6dd7eaa35c896ea170a10f2152c1d1b9be10fa606f06


$ ghci
GHCi, version 9.2.1: https://www.haskell.org/ghc/  :? for help
ghci>

(Foreshadowing: Wait a second! Where is the obligatory message "Loaded 
package environment etc etc"?)


ghci> import Data.Vector

: error:
Could not find module ‘Data.Vector’
Perhaps you meant Data.Functor (from base-4.16.0.0)

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Linking completely statically

[Albert Y. C. Lai]

On 2020-08-12 10:15 a.m., Volker Wysk wrote:

But it sounds quite complicated. What I have in mind isn't worth the
trouble. I just wanted to have a statically linked version for
inclusion in my backup and in my maintenance USB stick.


I have an exe built by GHC in January 2014 (that's like GHC 7.6), and it 
is still running just fine on the latest Ubuntu. (In fact I have a daily 
cron job that runs it.)


This is a data point for how long GHC default linking can last IRL.

Historically my recollection of the only one breakage event in this 
regard was a libgmp version bump. And that was a bygone era, clearly 
before my vintage 2014 exe.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Multiple C threads -> one unthreaded GHC RTS

[Albert Y. C. Lai]

Suppose I have a C program with multiple C threads calling Haskell 
functions, maybe the same Haskell function too, and the GHC RTS used is 
the unthreaded one. What will go wrong?


I ask because Cabal/cabal-install has recently added building of 
export-to-C shared libraries, i.e., the "foreign-library" section. It 
sees to all the technical details, very nice, I'm very happy about this 
addition, but it chooses the unthreaded GHC RTS.


Thanks.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Behavior of GHC_PACKAGE_PATH

[Albert Y. C. Lai]

On 2016-08-16 07:08 AM, Harendra Kumar wrote:

As per the GHC manual
(https://downloads.haskell.org/~ghc/master/users-guide/packages.html#the-ghc-package-path-environment-variable
),
packages which come earlier in the GHC_PACKAGE_PATH supersede the ones
which come later. But that does not seem to be the case always.

I am dealing with a case where I have multiple versions of a package in
different databases.


No, they don't mean multiple versions. They mean this:

For example if two databases both have HUnit-1.1 (important: same name 
and same version number), then that's when all the talk about overriding 
is relevant.


If you have different version numbers, the override rule doesn't apply, 
the rule that applies is the shadow rule: the highest version number wins.


The shadow rule exists because there are two scenerios that you really 
don't want to behave differently:


1. You have both HUnit-1.1 and HUnit-1.2, and they are in the same database.

2. You have both HUnit-1.1 and HUnit-1.2, but they are in different 
databases.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: How to remove a cabal package from the local system?

[Albert Y. C. Lai]

On 2015-01-21 10:36 AM, Volker Wysk wrote:

I have installed/registered a new version of a package with cabal by accident.
How can I remove it again?


See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact, 
read the whole thing.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Albert Y. C. Lai]

On 14-02-18 10:44 PM, Carter Schonwald wrote:

hey Albert, could you open a ticket on ghc Trac about the QuasiQuot thing?


It is now https://ghc.haskell.org/trac/ghc/ticket/8805
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Albert Y. C. Lai]

The new dynamism is pretty nice! I even used GHC 7.6.3 to build 
cabal-install 1.18, then played with PATH so that when I said cabal 
install mtl it saw GHC 7.8. It correctly added -dynamic-too and built 
both *.a and *.so in one go. This is very user-friendly.


Still, I observed a few oddities.

1. Referring to the user guide section 2.3 loading compiled code, it 
is now insufficient to ghc -c D.hs. It has to be ghc -c -dynamic D.hs.


Perhaps more importantly, ghc -c -dynamic-too D.hs is also 
insufficient. Apparently, while TemplateHaskell considers both *.hi and 
*.dyn_hi, :load considers *.hi only.


2. My experiment began with just QuasiQuote. QuasiQuote needs as much 
dynamism as TemplateHaskell. Yet, QuasiQuote does not trigger a nice 
implicit -dynamic-too, unlike TemplateHaskell.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: target audience for the binary distribution

[Albert Y. C. Lai]

On 14-02-08 01:33 PM, harry wrote:

Who actually are most users for the bindist? Debian  derivatives have the
latest GHC in the package repository


No. The other pasture is not greener. The distro you don't use is not 
more up to date. Chinese proverb: all crows in the whole world are 
equally black.


Debian and derivatives almost always have the wrong version. Wrong 
version means:


* Lagging behind Haskell Platform. And Haskell Platform is already very 
conservative and has its own wait-and-see period.


* If one version has a serious bug, then long after the bugfix version 
is released, Debian and derivatives still cling on to the bug. Here is a 
historical example: 6.12.1 had a serious bug, fixed in 6 months. Ubuntu 
10.04 and 10.10 both provided 6.12.1, this means 12 months of living 
with the bug for you. (10.04's case was justifiable, 10.10's was 
inexcusable.)

http://www.vex.net/~trebla/haskell/sicp.xhtml#ghc6121

I use the bindist.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 32-bit libs required for 64-bit install

[Albert Y. C. Lai]

On 13-08-25 08:48 AM, Yitzchak Gale wrote:

I had trouble installing the generic 64-bit Linux tarball for 7.6.3.
With some help from Ian, who pointed out that the problem was
related to ld-linux.so, I finally figured out the root of the problem:
the installation requires *both* the 64-bit and 32-bit
versions of libc6 plus deps to be available.

[...]

More details: the target system for the installation in my case
was an up-to-date Ubuntu 12.04 LTS (precise) amd64 headless
server running in a VMware containter.


On Ubuntu 13.04 Server x86_64, I cannot reproduce the problem.

  aptitude search '~i ~ri386'

outputs nothing, hopefully indicating that I have no 32-bit libs.

  ldd utils/ghc-pwd/dist-install/build/tmp/ghc-pwd

outputs:
linux-vdso.so.1 =  (0x7fff3bbfe000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f91861ef000)
libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f9185fec000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9185de7000)
libgmp.so.3 = /usr/lib/x86_64-linux-gnu/libgmp.so.3 (0x7f9185b78000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f9185873000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f91854aa000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f918528d000)

/lib64/ld-linux-x86-64.so.2 (0x7f91863ff000)

It seems that the OS's linker successfully selects 64-bit libs.

(I confess that my libgmp.so.3 is a symlink to libgmp.so.10.)

  ./configure --prefix=$HOME/g
and
  make install

proceed to completion.

I confess that I have not tried Ubuntu 12.04.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: change location of user's package directory

[Albert Y. C. Lai]

On 13-07-25 03:14 PM, harry wrote:

How can I change the location that ghc and ghc-pkg use for the user's package
directory? I'm running GHC in a very restricted environment where I don't
have access to $HOME, but I can use specific subdirectories.


Cannot. But you have another option. GHC and cabal-install support 
further package databases than global and user.


To initialize:

mkdir /joy (or other ways to make /joy exist and be empty)
ghc-pkg --package-db=/joy recache

Note: two hyphens, -- not -


To cabal-install:

cabal --package-db=/joy --prefix=/delight install acme-dont

Note: you must provide a custom --prefix. The default is $HOME/.cabal 
which is exactly what you can't use.



To ghc-pkg:

ghc-pkg --global --package-db=/joy list
ghc-pkg --package-db=/joy unregister acme-dont

However, beware of http://ghc.haskell.org/trac/ghc/ticket/5442


To ghc or ghci:

ghc -package-db=/joy

Note: one hyphen: - not --
(Don't you love to memorize random conventions.)
(In older versions of GHC, it was even better:
cabal --package-db=/joy
ghc-pkg --package-conf=/joy
ghc -package-conf=/joy
Don't you love to memorize random conventions.)

Read the full story in GHC User's Guide section 4.9 Packages. It comes 
with GHC on your hard disk.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: missing mtl (which exists) when installing filemanip package

[Albert Y. C. Lai]

On 13-01-10 10:34 AM, HP Wei wrote:

Question:
why can't $HOME/ghc/lib/mtl-2.0.1.0/
be recognized during the above Setup configure ??


You need to see my
http://www.vex.net/~trebla/haskell/sicp.xhtml

Existence of files is insufficient. Metadata trumps data.

But there is one point I don't understand in Brent Yorgey's theory.

Presumably, you are consistent, you also used Setup rather than cabal 
install for mtl. Therefore, mtl should also be in global.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using DeepSeq for exception ordering

[Albert Y. C. Lai]

On 12-11-12 11:34 AM, Simon Marlow wrote:

Did you try -fpedantic-bottoms?


Interesting option. And furthermore its doc refers to -fno-state-hack, too.

import Control.DeepSeq
import Control.Exception

main = do
  evaluate (('a' : error A) `deepseq` putStrLn hi)
  throwIO (userError B)

-O -fpedantic-bottoms = B
-O -fno-state-hack = A
-O both = A

7.4.2, linux 32-bit x86

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using DeepSeq for exception ordering

[Albert Y. C. Lai]

On 12-11-08 07:12 AM, Simon Hengel wrote:

I was just going to say that I can give at least one counterexample
where this does not hold:

   evaluate (('a' : undefined) `deepseq` return () :: IO ())
   throwIO exceptionB

But then I realized that here exceptionA is optimized away altogether.
For me this smells like a bug.  Is this related to [1]?

[1] http://hackage.haskell.org/trac/ghc/ticket/2273


Interesting. A few more tests (all GHC 7.4.2, linux, x86 32-bit, use 
ghc -O to compile):


The following cases throw A:

import Control.DeepSeq
import Control.Exception

main = do
  evaluate (('a' : error A) `deepseq` return () :: Maybe ())
  throwIO (userError B)

main = do
  evaluate (('a' : error A) `deepseq` ())
  throwIO (userError B)

main = do
  evaluate (('a' : error A) `deepseq` True)
  throwIO (userError B)

main = do
  x - evaluate (('a' : error A) `deepseq` putStrLn hi)
  x
  throwIO (userError B)

The following cases throw B:

main = do
  evaluate (('a' : error A) `deepseq` return () :: IO ())
  throwIO (userError B)

main = do
  evaluate (('a' : error A) `deepseq` putStrLn hi)
  throwIO (userError B)

main = do
  evaluate (('a' : error A) `deepseq` getLine)
  throwIO (userError B)

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using DeepSeq for exception ordering

[Albert Y. C. Lai]

On 12-11-08 01:01 PM, Nicolas Frisby wrote:

And the important observation is: all of them throw A if interpreted in
ghci or compiled without -O, right?


Yes.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: divRem by `-' performance

[Albert Y. C. Lai]

On 12-10-18 05:24 AM, Serge D. Mechveliani wrote:

And concerning this example: I am not even sure now that it worths to
setting  $!  there.
Because I deliberately program  qRem  as returning a pair  (quot, rem),
and do not program a separate function for  rem.  And to obtain  rem,
one applies   snd (qRem n m),  and due to laziness,  quot  does not
spend the cost. I do not know, may be, using $! may damage this style.


snd (quot, rem) does not spend the arithmetic cost of quot, but spends 
the memory cost of quot. Memory cost is not just occupation of memory, 
but also writing of memory and computing of addresses, which is not 
exactly cheaper than arithmetic.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: divRem by `-' performance

[Albert Y. C. Lai]

On 12-10-18 03:10 PM, Serge D. Mechveliani wrote:

But in this example of  qRem  the time is almost so as if  quot  was
not computed.
Probably, the coefficient of this expense is small.

On the other hand, an extra memory occupation also often causes slowing
down of all the environment program, because this occupation approaches
garbage collection.


Use ./Main +RTS -s -RTS to find out how hard the garbage collector has 
to work. Use ./Main +RTS -M64m -RTS to find out how much memory is not 
enough. We are speaking of snd (qRem n 5), of course.


(64MB ought to be enough for everybody.? :) )

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default instance for IsString

[Albert Y. C. Lai]

On 12-04-24 10:11 PM, wren ng thornton wrote:

To the extent that ByteString's instance runs into issues with high
point codes, that strikes me as a bug in virtue of poor foresight.
Consider, for instance, the distinction between integral and
non-integral numeric literals. We recognize that (0.1 :: Int) is
invalid, and so we a-priori define the Haskell syntax to recognize two
different sorts of numbers. It seems that we should do the same thing
for strings. 'String' literals of raw binary goop (subject to escape
mechanisms for detecting the end of string) are different from string
literals which are valid Unicode sequences. This, I think, is fair game
to be expressed directly in the specification of overloaded string
literals, just as we distinguish classes of overloaded numeric literals.
Unfortunately, for numeric literals we have a nice syntactic distinction
between integral and non-integral, which seems to suggest that we'd need
a similar syntactic distinction to recognize the different sorts of
string literals.


I have a cunning plan:

class IsList c e | c - e where
  fromList :: [e] - c
  -- requirement: must be a total function

instance IsList ByteString Word8 where
  fromList = ByteString.pack

instance Ord e = IsList (Set e) e where
  fromList = Set.fromList

{-# LANGUAGE OverloadedList #-}

example1 :: ByteString
example1 = [106,117,115,116,32,107,105,100,100,105,110,103]

example2 :: Set Word8
example2 = [106,117,115,116,32,107,105,100,100,105,110,103]

Please don't kill me!

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: cabal install version selection

[Albert Y. C. Lai]

On 12-03-30 06:37 PM, Christian Höner zu Siederdissen wrote:

I fail to remember or re-google the package version selection for cabal,
if no version constraints are given.

If I depend on iteratee, and there are no constraints, does it take
the lowest version?


It takes the highest version.

To verify, I fetched RNAFold.cabal of 1.99.1.0 and tried:

cabal install --dry-run

Its answer:

Resolving dependencies...
In order, the following would be installed (use -v for more details):
ListLike-3.1.4
MonadCatchIO-transformers-0.2.2.3
OneTuple-0.2.1
PrimitiveArray-0.2.1.1
ADPfusion-0.0.1.0
bytestring-lexing-0.4.0
cmdargs-0.9.5
csv-0.1.2
file-embed-0.0.4.1
iteratee-0.8.8.1
...

It chooses the newest iteratee alright.

I don't know what is going on with hackage's build bot. And I can't 
control it anyway.



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error while installing new packages with GHC 7.4.1

[Albert Y. C. Lai]

On 12-02-29 09:30 PM, Brent Yorgey wrote:

I wonder about the possibility of making a simple tool to parse the
output of cabal install -v3 and visualize/organize it in some sort of
way to make this process easier.  What might such
visualization/organization look like?


The most useful information is like this (let's say someone orders 
cabal install -v3 x):


will add array-0.4.999 for
  x-2.3's array = 0.4.999
  containers-0.4.2.1's array any
  Cabal-1.14.0's array = 0.1   0.5
  ignoring existing array-0.4.0.0
will replace containers-0.4.2.1 for
  Cabal-1.14.0's containers = 0.1   0.5
  change of array
  ignoring existing containers-0.4.2.1
will replace Cabal-1.14.0 for
  x-2.3's Cabal = 1.12
  change of array, containers, process
  ignoring existing Cabal-1.14.0
will add x-2.3 for
  command's x any

(remark: change of process happened in a previous session and noticed now)

Most of this information is not found the output of cabal install -v3.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error while installing new packages with GHC 7.4.1

[Albert Y. C. Lai]

On 12-02-29 06:04 AM, Antoras wrote:

I don't know where the dependency to array-0.3.0.3 comes from. Is it
possible to get more info from cabal than -v?


hoogle-4.2.8 has Cabal = 1.8   1.13, this brings in Cabal-1.12.0.

Cabal-1.12.0 has array = 0.1   0.4, this brings in array-0.3.0.3.

It is a mess to have 2nd instances of libraries that already come with 
GHC, unless you are an expert in knowing and avoiding the treacherous 
consequences. See my

http://www.vex.net/~trebla/haskell/sicp.xhtml

It is possible to fish the output of cabal install --dry-run -v3 
hoogle for why array-0.3.0.3 is brought in. It really is fishing, since 
the output is copious and of low information density. Chinese idiom: 
needle in ocean (haystack is too easy). Example:


selecting hoogle-4.2.8 (hackage) and discarding Cabal-1.1.6, 1.2.1, 
1.2.2.0,

1.2.3.0, 1.2.4.0, 1.4.0.0, 1.4.0.1, 1.4.0.2, 1.6.0.1, 1.6.0.2, 1.6.0.3,
1.14.0, blaze-builder-0.1, case-insensitive-0.1,

We see that selecting hoogle-4.2.8 causes ruling out Cabal 1.14.0

Similarly, the line for selecting Cabal-1.12.0 mentions ruling out 
array-0.4.0.0


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: named pipes

[Albert Y. C. Lai]

On 12-01-19 02:16 PM, Serge D. Mechveliani wrote:

-- Main.hs -
hPutStr h1 str
hFlush h1


This fails to send a newline.


--- fifo2.c -
   if (fgets(str, BOUND, toA) == NULL) {


This refuses to finish until it sees a newline (or BOUND chars, or the 
eof condition, or an error condition).


What really interests me is that if Main.hs is linked with -threaded, 
the deadlock is unlocked, and both programs proceed to completion.


This is because the -threaded runtime goes through garbage collection 
when idling (such as waiting for hGetLine). Since there is no further 
reference to h1 by then, GC hCloses it. That unlocks the fgets side.


This is fragile and not to be relied on. You will always have further 
references to h1 in practice.



Comparison with C - C
-
If both programs are in C, then the whole loop of the string exchange
(with  fifo2.c  rewritten into a loop) works as needed, both for the
variants with fgets and with `read'.


I am not convinced in the case of fgets. I cannot reproduce it. (Oh, I 
know read has a much better chance, it doesn't wait for a newline.)


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: named pipes

[Albert Y. C. Lai]

Main.hs does not open fromA at all. (fromA_IO is dead code.) This causes 
fifo2.c to be hung whenever it opens fromA. From the man page of 
mkfifo(3) on Linux:


Opening a FIFO for reading normally blocks until some other process 
opens the same FIFO for writing, and vice versa. See fifo(7) for 
nonblocking handling of FIFO special files.


In the sister thread in haskell-cafe, the addition of unsafePerformIO 
throws further disorder into these highly order-sensitive operations.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-pkg unregister disobedience

[Albert Y. C. Lai]

On 11-08-29 02:39 PM, Albert Y. C. Lai wrote:

ghc-pkg unregister --user P drops the global package if P is not in user.

[etc]

Now as ticket http://hackage.haskell.org/trac/ghc/ticket/5442

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-pkg unregister disobedience

[Albert Y. C. Lai]

For package P,

ghc-pkg unregister --user P drops the global package if P is not in user.

ghc-pkg unregister --global P drops the user package if P is in user.

ghc-pkg unregister --package-conf=dir P drops the user or the global 
package, preferring the user one, if P is not found in dir.


Same with ghc-pkg --user unregister P, ghc-pkg unregister P --user, etc.

GHC versions 6.10, 6.12, 7.0, 7.2.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why no stack overflow in ghci?

[Albert Y. C. Lai]

On 11-08-01 10:12 AM, Simon Marlow wrote:

On 26/07/2011 22:41, Albert Y. C. Lai wrote:

http://www.mail-archive.com/haskell-cafe@haskell.org/msg88368.html


The message linked here doesn't really explain *why*, rather it seems to
be a bug report on haskell-cafe (which I don't usually read, so it
doesn't get fixed!).


Indeed, I didn't want it fixed. I loved that backdoor. XD

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why no stack overflow in ghci?

[Albert Y. C. Lai]

On 11-07-26 03:57 PM, Roman Cheplyaka wrote:

The code

   main = print $ foldl (+) 0 [1..100]

when compiled (without optimizations) results in a stack overflow, which
is expected.

However, when run from ghci it succeeds. Why is it so?
(Tested with GHC 6.12.something and 7.0.4)


To enjoy unlimited stack in compiled code, add +RTS -K10

To enjoy limited stack in ghci, add +RTS -K8M

To know why, see my
http://www.mail-archive.com/haskell-cafe@haskell.org/msg88368.html

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: haskell-platform configures failed on Ubuntu 11.04

[Albert Y. C. Lai]

On 11-07-22 02:26 PM, David Smith wrote:

I tried to build the newest haskell-platform-2011.2.01 from source on
Ubuntu 11.04, following the instructions
http://www.vex.net/~trebla/haskell/haskell-platform.xhtml. But there was
still an configure error.

[...]

checking for library containing glEnd... no
configure: error: The OpenGL C library is required

[...]

The following are the libraries I already installed

sudo apt-get install libgl1-mesa-dev
sudo apt-get install libglc-dev
sudo apt-get install freeglut3-dev
sudo apt-get install libedit-dev
sudo apt-get install libglw1-mesa libglw1-mesa-dev


I just tested again in a fairly clean Ubuntu 11.04 (Desktop) 
installation plus the concerned *-dev packages (first just those in my 
instructions, then plus your extra ones) plus ghc 7.0.3. I cannot 
reproduce the error. The configure script figured out


checking for library containing glEnd... -lGL

just fine. There was no error.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Package management

[Albert Y. C. Lai]

On 11-04-26 05:05 PM, Brandon Moore wrote:

There are already hashes to keep incompatible builds of a package separate.
Would anything break if
existing packages were left alone when a new version was installed? (perhaps
preferring the most
recent if a package flag specifies version but not hash).


Whether we allow multiple builds of same package same version, or allow 
multiple versions of same package, we face the same dilemmas:


First dilemma: If the package comes with C code, you get a name clash at 
the C level. Because C function names in such packages are unlikely to 
vary by version. Well, the linker sees two extern C functions both 
called get_current_timezone_seconds (real example from the time 
package), great.


Second dilemma: If the package comes with instance code like instance 
Read (IO a), you get overlapping instances.


Third dilemma: Data types and type classes defined by the package cannot 
be safely exchanged between two users because the two users depend on 
two different builds. Perhaps it is safe in most cases, but you can't be 
too sure.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

hot-refreshing a package (same version number, new content)

[Albert Y. C. Lai]

Suppose I start ghci, use a value from a package, causing it to be 
linked, then I modify the package and reinstall, same version number, 
without quitting my ghci session. Is there a way to tell the ghci 
session to refresh and use the modified package?


Suppose I do something similar with the GHC API (6.12.3, linux, x86, 32 
bit). The attachment g.hs is my program to get a value from the package 
(called watermelon-0.1), print it, wait for me to press return, (at this 
point I modify the source code of the package, rebuild, reinstall), then 
loop back to get a value from the package again... how should I refresh 
so I get the new value?


Or I am supposed to forget this and just bump the version number of the 
package?


I attach my program g.hs and the package tarball for watermelon-0.1.
import Control.Monad(forever,liftM)

import GHC
import Unsafe.Coerce(unsafeCoerce)
import GHC.Paths(libdir)
import DynFlags(defaultDynFlags)
import Linker(getHValue,initDynLinker,linkPackages,showLinkerState)
import Module(mainPackageId,stringToPackageId)
import Name(nameOccName)
import OccName(isValOcc,occNameString)
import MonadUtils(liftIO)

main = forever $ do
  e - ghcheader (unsafepkgget watermelon-0.1 W wm)
  print (e :: Int)
  getLine

ghcheader :: Ghc a - IO a
ghcheader body = runGhc (Just libdir) $ do
  f0 - getSessionDynFlags
  let f = dfmod f0
  defaultCleanupHandler f $ do
todo - setSessionDynFlags f
f1 - getSessionDynFlags
liftIO (initDynLinker f1)
body
  where dfmod f = f{ghcLink=LinkInMemory}

unsafepkgget :: (GhcMonad m) = String - String - String - m a
unsafepkgget spkg smod sval = unsafeget (pkgmod spkg smod) sval

pkgmod :: String - String - Module
pkgmod spkg smod = mkModule (stringToPackageId spkg) (mkModuleName smod)

unsafeget :: (GhcMonad m) = Module - String - m a
unsafeget m v = do
  mi - getModuleInfo m
  case mi of
Nothing - error (unsafeget fails at  ++ mns)
Just i - do
  case filter (match v) (modInfoExports i) of
[n] - do h - getSession
  liftIO $ do
val - unsafeCoerce `liftM` getHValue h n
-- showLinkerState
return val
_ - error (unsafegetval cannot find value  ++ v ++
 in module  ++ mns)
  where mns = moduleNameString (moduleName m)
match s n = let o = nameOccName n in isValOcc o  s == occNameString o


watermelon-0.1.tar.gz
Description: GNU Zip compressed data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Modules and their explicit export lists (are an annoyance)

[Albert Y. C. Lai]

I write an export list because I want to help Haddock. It suffices to 
export a constructor with (..) for this, if I intend to.


How much to export is always politics, bargaining, negotiation, social 
dynamics. There will always be someone annoyed. Exporting too much 
reduces annoyance now by re-paying for annoyance plus interest in future 
when an exported item will be withdrawn or visibly changed.


Discuss with the authors if you believe that more should be exported.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker's expected and inferred types (reformatted)

[Albert Y. C. Lai]

For the record, and to speak up as part of a possible silent majority,

I completely understand the type error messages. I find enough 
information in them. I like them.


I find it unnecessary to decrypt the two words expected and 
inferred. They have their own definitions and they stand for 
themselves; external and internal are helpful mnemonics, useful 
approximation, but not decryption.


I support work on ghc to prioritize professional use over pedagogical 
use, that is, if a proposed pedagogical improvement conflicts with 
professional use concerns, or even if simply no one has time to 
implement, I support sacrificing the pedagogical improvement. To 
mitigate the sacrifice, we users write tutorials for each other.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Having trouble with parallel Haskell

[Albert Y. C. Lai]

I do not have a platform to try it on; the following is pure speculation.

In main, the builder of input is highly lazy, since randoms is. To be 
sure, the spine of the list is presently forced by printing its length, 
but the numbers inside the list... It is very bleak because randoms 
ensures that input!!(n+1) is patently dependent on input!!n, ad 
infinitum; this should defy all attempts at parallelism...


Forcing the numbers themselves before sorting will give a much more 
conclusive result, success or failure.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.6.1

[Albert Y. C. Lai]

Duncan Coutts wrote:

Is it just me who thinks this is a silly idea? Why should GHC include a
C++ compiler?


I'm afraid it's just you. Like that someone who has indicated interest 
in haskell-c++ integration, I am interested in the prospect of mixing 
haskell with .NET languages, and not to mention that everyone, not just 
.NET literates, will benefit from the many libraries available in .NET. 
Can we also include a .NET runtime, a .NET documentation suite, all .NET 
libraries, a C# compiler, a VB compiler, and an F# compiler in a future 
GHC package for Windows? In fact also the corresponding Mono suite in 
the Linux case? Yes, I understand that a bridge between GHC and .NET 
does not exist yet, but consider this. In the spirit of everyone is 
invited to help! whenever there is a demand and not yet a supply in the 
Haskell community, we should encourage everyone to help add this missing 
bridge, and what better way is there if not ship a complete .NET suite 
in GHC so all interested parties can hack or test right away! And since 
this requires hacking the source code of GHC, wouldn't it be nice if the 
binary tarball also included the source tree? And also darcs since we 
will be crazy pushing and pulling?


I am not done yet. An ideal of .NET, at least for frontline developers 
if not for corporate Microsoft, is to be portable throughout Windows, 
Linux (via Mono for example), BSDs, MacOS, Solaris,... At present let's 
say just Windows and Linux in practice. Someone on Windows Vista without 
Linux will not be able to test out the bridge under construction on 
Linux. Someone on Linux without Windows Vista will not be able to test 
out the bridge under construction on Windows Vista. This is a sorry 
state of affair. To help developers and testers (and remember everyone 
is invited to help!), I have this bright idea: The GHC binary for Vista 
should include Linux, and the GHC binary for Linux should include Vista! 
(The GHC binary for MacOS should include both Linux and Vista!)


The last suggestion raises licensing issues, I am aware. We can't give 
away Vista just like that. We have to distribute it legally. The GHC 
team should extend itself (e.g., hire me!) to set up a lightweight 
e-Commerce company, authorized by Microsoft to sell Vista licences and 
releases. Then it can legally distribute GHC+Vista packages. (Of course 
you will have to pay, and the payment will find its way to Microsoft.) 
Collaboration with MSDN is also possible. This opens up a whole new 
dimension where no one has gone before! Just look at IBM: We don't sell 
products, we sell services brought them great success, in fact brought 
them out of great crisis into great success. If the GHC team also goes 
we don't release compilers, we release complete platforms, the 
prospect is beyond imagination and its profoundness beyond expression.


How should I file this to the bug track? Should I file one monolithic 
report containing the whole shebang above? Or should I re-factor it into 
a million piecemeals and file each individually?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users