to be too lax or too tight.
+1 from me.
To give you an idea what I had to patch in the past:
http://github.com/MarcWeber/haskell-nix-overlay/tree/master/patches/
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Today I spend quite a while figuring out why I could install base<4
while using flag base4.
The reason was that I forgot to add the label build-depends: when
patching.
If those lines are ignored shouldn't there be a warning?
Marc Weber
name:QuickCheck
version:1.2.0.0
license:BSD3
adding it!
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Wed, Oct 08, 2008 at 12:37:08PM +0100, allan wrote:
> Hi Marc
>
> Yes this is possible using the 'Buildable' field.
>
> executable webinterface
> build-depends: cgi, xhtml
> Main-is: web/yyyWebInterface.hs
> Extensions: PatternGuards ScopedTypeVariables
> Ghc-options
Hi,
Can I enable/ disable executable by flags ?
eg this way:
= ===
Name:x
category:web application
version: 0.0.1
Cabal-Version: >=1.2
build-type: Simple
LICENSE: GPL
extensions: CPP
cp
> I've also wondered if the command line UI could be completely separated,
> though that could make bootstrapping too hard.
You could distribute a "bootstrapping" version of cabal shipping with the
command
line UI as hidden modules.
If you build cabal later on you could just shipt without the file
as malicious ..
Of course the package might become malicious only on Monday or after
9.11.2011 etc.. but obvious packages which would hurt hundreds of people
could be catched this way easily. All we would need is a build system.
Of course we can't do anything about this only no Monday p
flying around.
You can't forget about all trouble.. just about some incompatibilies.
Any thoughts?
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
ckageInfo] ) <- fmap read $ myReadFile
Creating a map sorted by names without versions and then listing/
removing old duplicates should be trivial.
I've never really worked on a mac.. So maybe this all doesn't apply to
you.
Sincerly
Marc Weber
__
I'm using
./setup configure && ./setup build
very often and hope that it just works (which it really does most of the
time :)
However sometimes it might be interesting to know which flags are
chosen..
Do you think it would be useful to show the chosen flags by default (not
only when using -v3) ?
I
ckage name (version 0.3) _LATEST_
...
Other versions : 0.2 0.4
is easiest to spot ?
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
bal. But it's good to know how it can / should be done
in the future.
Sincerly
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
ering about
default values and how things are used internally within Cabal.
(I mean wether and when defaultConfigFlags is actually used so it's safe
to use .. you know this already from my privious post :)
I don't want to break things.. I only want tell you about my thoughts.
> It's used in cabal-install; http://darcs.haskell.org/cabal-install
> I can agree the flag business seems confusing at first.
so adding simple comments is the best choice then :)
Thanks Marc
___
cabal-devel mailing list
cabal-devel@haskell.org
http:/
en if you haven't specified the arg?
c) maybe do b) but keep raw args somehow to print them again instead
of printing -v unless -v is given?
Sincerly Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Mon, Jan 14, 2008 at 01:50:15AM +0100, Marc Weber wrote:
> Discussion moved to the haskell mailinglist.
Sorry for this inconvinience.
I think haskell-cafe is the better choice right now
Marc
___
cabal-devel mailing list
cabal-devel@haskell.org
h
Discussion moved to the haskell mailinglist.
I'll try keeping the Trac page up to date by adding summaries
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
I've been using the recent cabal from ghc-6.7.20070814
register.sh
[...]
haddock-html:
/pr/store/5wivrfz8pmc7hpwqgxgz44i4ihf1ka09-ghc67_filepath-1.0/nix-support/share/filepath-1.0/doc/html/filepath'
| /pr/store/khvbwb3whj1c15pg7jrh7w4v2vndr8i7-ghc-6.7.20070814/bin/ghc-pkg
update dist/installed
there too) when the trouble appears again.
Thanks for digging up the bug report
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
when invoking
runhaskell setup.hs copy
I'm getting
*** Exception: waitForProcess: does not exist (No child processes)
When using ghc -make setup; ./setup ...
the problem doesn't appear.
Any idea what might causing this.
Using runhaskell is much faster then compiling setup.
When I have more
I don't know the internals of hackage very well, but I think the most up
to date version should be shown first?
Example where its not the case:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TypeCompose-0.0
Marc Weber
___
cabal-
> Sounds very cool. *However* the output will not be portable,
It dasen't have to be portable. That's why you have your source
distribution.tar.gz or darcs repa..
I just want a bunch of files which I can feed intto haddock or any
other developement tool (tag generation etc)..
If you need to ref
ovide compiler
independent completion etc?
eg ./setup haddock on haddock sources itself fails on line
#if defined(mingw32_HOST_OS)
...
What do you think?
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/lis
;
log-hackage-unix-2.0:Couldn't match expected type `CInt' against inferred
type `CMode'
log-hackage-vty-3.0.0:Couldn't match expected type `CInt' against inferred
type `CMode'
log-hackage-xmobar-0.5:Couldn't match expected t
The following packages are listed more than once:
"Crypto"
"GuiTV"
"TypeCompose"
"Win32"
"binary"
"polyparse"
That's not by accident, is it?
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
I'm packaging all hackage packages for nix. I've already compiled 102
packages succesfully.
Is there a simple way to do a
./setup haddock --dirs-containing-dep-docs=path1;path2;path3;path4 ..
--install-to $out/haddock ?
If not who is working on haddock stuff right now?
Marc
if you find
regex-compat, right? Is this intentionally?
Mmmh This means I must iterate over the whole dependency tree to collect
them all.
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
uld we add a warning when uploading packages to hackage?
or when building with cabal?
Then this problem would be banned ;)
I think it won't harm anyone but prevent some issues. Thus it's a good
thing.
Marc Weber
___
cabal-devel mailing list
c
y
versions with that name as well (Long before it has been uploaded to
hackage).. But it might be the case that just I had given it this name.
I've tried installing hpodder some days ago. That's why I was faced this
problem more frequently ;)
Marc Weber
_
Hi Ross. (CC cabal-devel)
I'm adding all packages from hackage to the nix distribution system.
However I'v noticed some small issues.
(eg Renaming FilePath -> filepath)
Should I fix the issues in nix only or should I fix the packages on
hackage?
If so I would need an account on h
would be overkill but would work fine..
Sorry. I have no experience with that.
The t2-project.org does have somehting simlar as well (don't know which
kind though)
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/ma
> works with any token type tok.
Sorry. You are right.
You can customize the error position depending on token type.
Eg when parsing command line arguments tracking a line number doesn't
make sense.
Some time has passed since having done this .. ;(
Marc
cause a big
speed penalty?
http://mawercer.de/marcweber/haskell/darcs/fparsec/
I've used this to create an experimental command line parser which works
fine.
Marc Weber
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailma
> The --destdir is like automake's "make install DESTDIR=$TMP/blah"
> feature. But using configure --prefix should change what register
> --gen-script produces, so if that's not happening then it's a bug I
> think.
Perhaps I should tell you what I am about to do.
I want to register some cabal pack
I can use ./setup copy --destdir to copy all hi files etc to some
directory.
But how do I register it then?
Setting --prefix when using configure does'nt seem to adjust the
register.sh
using --gen-script I just can't add --destdir.
What am I missing?
Marc
On Mon, Mar 12, 2007 at 05:43:00AM +, Ashish Hanwadikar wrote:
> Marc Weber gmx.de> writes:
> > addDependencies = case stringOption "pretty_print_lib" of
> >
> > This should use the correct dependency if the option has already been set by
> > cmd
> Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools
> that read the .cabal file and perform operations based on the package
> metadata.
In which information are they particularely interested?
Am I right that they the main goal is getting to know which are the
source files and wh
> 2) Can you get rooted getting the license out of an application.
> Cabal, no, Haskell yes.
I'm not sure wether I get this sentence right.
What do you mean by "getting rooted" ?
Marc
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskel
> >> Remember: Cabal isn't only the build infrastructure, it's also the
> >> metadata format that tools like Hackage use. If you decide to combine data
> >> and code, you will no longer be able to manipulate the data with another
> >> tool.
> Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are
On Fri, Jan 12, 2007 at 01:23:37PM -0800, Conal Elliott wrote:
>Hi Marc.
>See Paul Hudak's [1]position paper on DSELs, where you'll find
>definition, motivation & examples. See also [2]Peter Landin's "Next
>700" paper. If you have questions, please ask!
>BTW, I hear both "EDSL
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-January/011854.html
This mail posted to glasgow-haskell-users by Samuel has been forwarded to
[EMAIL PROTECTED] by
Simon Peyton Jones as well
Cheers
Marc
___
cabal-devel mailing list
cabal-deve
On Wed, Jan 10, 2007 at 06:53:43AM -0800, Isaac Jones wrote:
> The original design of Cabal was more like Marc suggests. There was
> only the Setup file and no .cabal file, and my hope was that we'd
> build an EDSL for package configurations. Original cabal code would
> probably look like:
>
> m
On Tue, Jan 09, 2007 at 07:41:57PM -0800, Conal Elliott wrote:
>Marc points out that the expressiveness of the Cabal language is
>insufficient for some packages, and a DSEL would be more expressive.
Sorry, I've never heard abaut DSEL yet.
I still feel like beening a total beginner.. ;)
But
On Wed, Jan 10, 2007 at 01:39:08AM +, Neil Mitchell wrote:
> Hi Marc,
>
> [Snip]
>
> >Any ideas, comments?
> >
> >Anyone out there who wants to join and help implementing this idea?
>
> I'd ask why there is a Setup.hs file at all, a nice textual
> declarative form seems much more sensible.
ld"
sourceDir "src" $ mainIs "HelloWorld.hs"
addDependencies = case stringOption "pretty_print_lib" of
"A" : [LibVersionRange "A" "1.0 - 2.0"]
"B" : [LibVersionRange "B" "1.0 - 2.0"]
pac
If we want to add debugging support consider a packagetree like this:
a - b ( depends on b and c, c on d and e)
|
+ - c - d
|
+ - e
its obvious if I want to have a profiling lib a I need b..e compiled
with -prof, too
But if I want to build it with debugging messages what about b,c,d,e
I've read the discussion about who is able to upload packages..
This is nice if you want to install most common packages..
But the packaging system is intended to save time. Thus what about
I want to install an experimntal synthesizer which uses an experimental
haskore interface from a person who
Isaac showed me the Wiki.
But I'm missing some pages discussing how hackage and tools should look
like or pages which summarize decisions having be made on this list..
I think this missing because everything is in an early developement stage,
right?
What about adding some pages with summaries ?
t
> -- = moduleToPossiblePaths searchP s' suffs
>
> -- -- |Like 'moduleToFilePath', but return the location and the rest of
> -- -- the path as separate results.
> -- moduleToFilePath2
> -- :: [FilePath] -- ^search locations
> -- ->
$ ghc -o setup --make -package Cabal-0.1.7 setup.hs
Linking setup ...
ghc-6.5.20060917: unknown package: Cabal-1.1.7
I don't understand this.
I've substituted
Version 1.1.7 by 0.1.7 to get a low version which won't be used unless
requested.
This is the only Cabal package beeing installed.
ponse
Marc Weber <[EMAIL PROTECTED]> writes:
> Hi Isaac Jones.
Hi, Marc, thanks for writing. There's a cabal-devel mailing list
where you can post questions so that others can take a crack at
answering them, and they can get archived on the internet :)
> I wanted to learn mor
51 matches
Mail list logo
