Re: [Haskell-cafe] hledger subcommand detection, RFC
* an option to all commands that lists out all its available options, to aid with shell completion. See the link I posted above about the oggz tools for an example usage and a link to a bash completion file. Note that the next version of CmdArgs will include command line flag completion automatically, so you might want to leave that feature a little while and see if you can make use of the CmdArgs feature. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] extending and reusing cmdargs option specs ?
Hi,
You're asking for:
http://code.google.com/p/ndmitchell/issues/detail?id=291 - it's
something I'm already aware of, and what to do at some point.
Unfortunately, it probably won't be anytime in the next few months,
but it will happen eventually.
Thanks, Neil
On Tue, Aug 9, 2011 at 3:08 AM, wren ng thornton w...@freegeek.org wrote:
On 8/8/11 1:59 PM, Simon Michael wrote:
And, I may have made things worse for myself in the reuse/avoiding
boilerplate department: I'm not sure how to reuse a cmdargs options data
structure, extending it with a few more options.
This is a big problem I'm dealing with too lately. In particular, what I
would like is if cmdargs could do flattening of structures, either
automatically or with a new annotation combinator. With this it would be
easy to have a basic FooBar program:
data FooBar = FooBar
{ foo :: Foo
, bar :: Bar
}
deriving (Data, Typeable,...)
getFooBarMode :: IO (Mode (CmdArgs FooBar))
getFooBarMode = ...
and then extend it to a FooBarBaz program:
data FooBarBaz = FooBarBaz
{ fooBar :: FooBar
, baz :: Baz
}
deriving (Data, Typeable,...)
getFooBarBazMode :: IO (Mode (CmdArgs FooBarBaz))
getFooBarBazMode = ...
The big trick is that I should be able to call getFooBarMode from
getFooBarBazMode equivalently to if I had defined,
data FooBarBaz = FooBarBaz
{ foo :: Foo
, bar :: Bar
, baz :: Baz
}
deriving (Data, Typeable,...)
and copied over getFooBarMode inline into getFooBarBazMode. The problem is
that the bulk of the code is in the Mode-generating functions, and it's also
the sort of code that's hardest to keep in sync documentation-wise.
I don't mind the extra indirection in the Mode structures since I don't
actually use them in the program itself; I have an internal configuration
type that I compile the FooBarBaz down to, so that I can perform additional
semantic consistency checks before execution, as well as precomputing what
the commandline arguments dereference into (e.g., functions).
As always, thanks a lot for cmdargs!
-Simon
Indeed. Aside from this feature request I've been quite pleased :)
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package descriptions on hackage
There are several problems here: 1) Not everyone can write beautiful clear English descriptions, it takes a certain skill. 2) The person writing the description is the author, who knows all the details, but the person reading the description doesn't - writing for a different audience is an even harder skill to master. 3) It's easy to miss something when updating a package. 4) Quality documentation places an ongoing maintenance burden on the package, and while test suites etc. make code maintenance easy, I don't know any way to automatically check documentation! Why not email the maintainers of packages you think need a better description - ideally giving suggestions? I'd welcome that for any of my packages. Thanks, Neil On Mon, Sep 5, 2011 at 11:22 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 September 2011 23:59, Joachim Breitner m...@joachim-breitner.de wrote: Dear hackage package authors, this is a short message from your distribution package creators: Please, if possible, write good, not too short descriptions, and also keep them up to date. Of course, users browsing hackage will benefit as well. Also for potential users trying to work out what your library does! Something that I find particularly frustrating is all the libraries of the form hFoo: Haskell bindings to the Foo library; well, what _is_ the Foo library? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.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] .ghci files (Was: ANN: cabal-ghci 0.1)
Hi, Am Samstag, den 10.09.2011, 19:34 +0200 schrieb Erik Hesselink: On Sat, Sep 10, 2011 at 18:51, Joachim Breitner m...@joachim-breitner.de wrote: Am Samstag, den 10.09.2011, 11:26 +0200 schrieb Erik Hesselink: Did you know you can also put a .ghci file in your project dir, and if you start ghci from that dir, it will also load that file? I think that allows you to replicate some of the functionality of this tool, since it allows per project ghci options. is this well known and documented enough? It seems to me that most people would not expect that running ghci in a directory can cause arbitrary commands to be executed. This could be a security issue, e.g. running ghci in a just downloaded software package with a rouge .ghci file... but I am not sure what can or should be done about it. Running ghci runs template haskell, which can already run arbitrary code. Not that that fact makes this more secure, but if you don't trust the Haskell packages you're installing, there are larger security issues than .ghci files. yes, but this requires actively loading a file. Executing arbitrary commads when someone starts ghci in a rouge folder (consider an examiner on a multi-user machine at a university) is of a different quality. Especially as the file is hidden – TH code can easily be checked for before. Also it affects invocations ghc -e, which conceivably could be used in aliases for some action unrelated to running a ghci session, as in http://www.joachim-breitner.de/blog/archives/156-Haskell-on-the-Command-Line.html Maybe the file shouldn’t be hidden, this would give some protection. Alternatively, ghci could keep a white-list of files somewhere ~/.ghci and ask if it should execute a .ghci file that has not been encountered before. I just noticed that it will not read files in directories not owned by you and warn you about it (e.g. in /tmp), which is a good start. But this does not help against files in packaged repositories. Greetings, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package descriptions on hackage
On Sun, 2011-09-11 at 11:37 +0100, Neil Mitchell wrote: There are several problems here: [..] Why not email the maintainers of packages you think need a better description - ideally giving suggestions? I'd welcome that for any of my packages. Maybe something similiar to http://kernelnewbies.org/KernelJanitors could be done, e.g. HackageJanitors. Those HackageJanitors could also help making new GHC releases smoother by providing efficiently the usual minor fixes to hackage libraries breaking by new GHC releases (updating library version constraints, fixes related to GHC becoming less tolerant, adapting to Cabal changes). Maybe they could also be given the privilege to upload trivial fixes to hackage directly (possibly with a version indicating such a maintainer-override upload) if the library maintainer takes too long to respond or has generally opt-ed in for to such a auto-maintaince service (maybe by a new flag in .cabal files). cheers, hvr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
Sergiy, Tom,
Thanks for your replies.
Sergiy, I was able to get this working without having to recompile my
installed Haskell libraries.
Tom, you were correct; I needed to explicitly link against the Haskell
run-time system, as well as a few other things:
I changed my ghc link options from this:
HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static
to this:
HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts
-L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt
and things are working.
(The command that builds my mixed language, shared object library,
`libami.so', is:
ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and Haskell}
)
I can understand why I'd have to explicitly link against `libHSrts',
since I'm asking ghc for a shared object library and not an
executable. However, I'm not sure about the following:
- Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems
like ghc ought to know about that, implicitly.)
- Why do I need to explicitly link against the 3 standard C libraries:
`m', `ffi', and `rt'? (I've never needed to do this, previously, when
I was building/testing this project statically.)
Thanks, in advance, for any insights!
-db
On 9/10/11, Sergiy Nazarenko nazarenko.ser...@gmail.com wrote:
I've recompiled my library again and now it works without any problem.
Probably I made mistake somewhere.
Cheers,
Sergiy
___
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] ANN: Netwire 1.2.4
Hello there,
version 1.2.4 of netwire is out. Major changes:
* Changed the semantics of time. Previously if a wire was not run
(because of an earlier inhibiting wire), then its local time was
suspended. Example:
proc _ - do
t1 - time - ()
fps1 - avgFps 1000 - ()
require_ wackelkontakt - ()
t2 - time - ()
fps2 - avgFps 1000 - ()
identity -
printf Time: %8.2f %8.2f\nFPS : %8.2f %8.2f
t1 t2 fps1 fps2
In the previous version t2 would be about half of t1, because the
{require_ wackelkontakt} wire inhibits for about half of all
instances. Further fps1 and fps2 would be about equal. In other
words, time was local, while FPS were global. This is not very
useful in practical applications.
With the new semantics t1 and t2 will be equal. Instead the
framerate will drop after the inhibiting wire, such that fps2 will
be about half of fps1. So now time is global and FPS are local.
This is useful e.g. in a stateless network application (like a web
app) to ban users, who are trying logins too fast. The following
wire allows one login trial per second in average over the last 10
trials (the faster you try the longer you have to wait):
login :: Wire MyApp IpAddress User
login = context $ proc ipAddr - do
fps - avgFps 10 - ()
require_ - fps 1
{- login procedure -}
Used with ArrowPlus this easily lets you fetch the currently logged
in user from the session, and if there is none, request a login:
getUser :: Wire MyApp IpAddress User
getUser = getCurrentUser + login
* Context-sensitive wires. There is now a new wire transformer called
'context', which is essentially a context switcher establishing
multiple wire threads of control:
context :: (Ord a, Monad m) = Wire m a b - Wire m a b
It takes a base wire and evolves it individually for each possible
input value. This is a very convenient alternative to parallel
routing switches.
The 'context' wire transformer never forgets a context. For many
applications (like sessions in a web application) this is not
desirable. For them there is an alternative transformer
'contextLimited', which allows you to garbage-collect.
Minor changes:
* More responsive calculus wires. Reflect changes immediately without
the one-instant delay. If you need the delay for feedback, use
'delay' explicitly.
* New analysis wires 'collect' and 'lastSeen'.
* New inhibition wires 'forbid_', 'inhibit_' and 'require_'.
* Separate session starting/cleaning functions in FRP.NetWire.Session.
However, the exception-safe withWire function is the preferred way.
* Optimized internal representation. There are now only two
constructors WGen and WArr for the Wire type instead of four. I
dropped WConst and WId, because they are representable as special
cases of WArr without noticable performance loss. This improves
overall performance, because now there are only two constructors to
pattern-match against.
Right now I'm working intensively on netwire, so if you have any feature
requests, just mail me. There is a good chance to find your desired
feature implemented quickly.
Note: I have been too quick with version numbers. Major version 2 will
be the one with the stabilized API, so for now with increasing minor
version numbers (but not patch levels!) you have to be prepared for API
changes, although I don't expect big changes anymore.
Enjoy and keep the feedback coming!
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife = sex)
http://ertes.de/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
Hi, Captain,
As far as I see you try to build static library.
If this correct, what did not work in static library?
Why do you decide compile with -dynamic option?
I was trying to build shared library. Other python library has used
some functions from library which I had written using Haskell. But
some software which we use in my company had crached after attempts to
import python module. Under pure python it works OK, but software has
crached. I thought having static library to solve my problem. And I'm
looking for how to build static library, but no luck.
Cheers,
Sergiy
On 11 September 2011 17:56, Captain Freako capn.fre...@gmail.com wrote:
Sergiy, Tom,
Thanks for your replies.
Sergiy, I was able to get this working without having to recompile my
installed Haskell libraries.
Tom, you were correct; I needed to explicitly link against the Haskell
run-time system, as well as a few other things:
I changed my ghc link options from this:
HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static
to this:
HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts
-L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt
and things are working.
(The command that builds my mixed language, shared object library,
`libami.so', is:
ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and Haskell}
)
I can understand why I'd have to explicitly link against `libHSrts',
since I'm asking ghc for a shared object library and not an
executable. However, I'm not sure about the following:
- Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems
like ghc ought to know about that, implicitly.)
- Why do I need to explicitly link against the 3 standard C libraries:
`m', `ffi', and `rt'? (I've never needed to do this, previously, when
I was building/testing this project statically.)
Thanks, in advance, for any insights!
-db
On 9/10/11, Sergiy Nazarenko nazarenko.ser...@gmail.com wrote:
I've recompiled my library again and now it works without any problem.
Probably I made mistake somewhere.
Cheers,
Sergiy
___
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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
On Sun, Sep 11, 2011 at 10:56, Captain Freako capn.fre...@gmail.com wrote: I can understand why I'd have to explicitly link against `libHSrts', since I'm asking ghc for a shared object library and not an executable. However, I'm not sure about the following: - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems like ghc ought to know about that, implicitly.) - Why do I need to explicitly link against the 3 standard C libraries: `m', `ffi', and `rt'? (I've never needed to do this, previously, when I was building/testing this project statically.) The first is because GHC doesn't link its libraries using -L and basenames, but full path names. Since you used a basename, you also have to use -L to tell it how to expand the basename. The second is because those libraries are needed by libHSrts, and since you linked that explicitly you need to link its dependencies explicitly as well. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Functional Programming eXchange 2012: Call for abstracts
Hello all, I’m sending this email to several mailing lists so my apologies if you see this twice. Functional Programming eXchange is a developer conference that focuses on functional programming. The 2012 edition will take place on Friday March 16th March 2012, at the Skills Matter eXchange, in London. Typically talks are explore concepts that often crop up in functional programming such as parallelism or domain specific languages, look at frameworks built in functional languages or are cases studies of using functional programming in industry. Previous speakers have included: Simon Peyton Jones, Miles Sabin, David Pollak, Adam Granicz, Antonio Cisternino, Tomas Petricek, Jonas Boner, and Viktor Klang. Videos of the talks at the previous events can be found here: http://skillsmatter.com/event/scala/functionalpx-2011 http://skillsmatter.com/event/cloud-grid/functional-programming-exchange-2009 If you are interested at speaking at this conference please send a talk abstract to talks_functiona...@skillsmatter.com. I’m aiming to make the decision about which talks have been chosen around 14th October so if you submit an abstract expect to hear from me around this time. Kind regards, Robert ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] extending and reusing cmdargs option specs ?
On 9/11/11 6:11 AM, Neil Mitchell wrote: Hi, You're asking for: http://code.google.com/p/ndmitchell/issues/detail?id=291 - it's something I'm already aware of, and what to do at some point. Unfortunately, it probably won't be anytime in the next few months, but it will happen eventually. Yep, that's the one :) I'd offer to send a patch, but last time I looked at cmdargs I couldn't quite figure out how the internal representation all fits together. Do you have a blog post that talks about the guts of cmdargs rather than the user-facing side? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package descriptions on hackage
On 9/11/11 6:37 AM, Neil Mitchell wrote: Why not email the maintainers of packages you think need a better description - ideally giving suggestions? I'd welcome that for any of my packages. +1. I always love to hear that my packages are useful to someone. And if someone says hey this is useful, but here's something to make it even more useful that's awesome. Of course, requiring feedback in order to improve places an undue burden on the users; the maintainers should be trying to save users from that labor. But everything has to start somewhere. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package descriptions on hackage
On Sun, Sep 11, 2011 at 13:14, wren ng thornton w...@freegeek.org wrote: On 9/11/11 6:37 AM, Neil Mitchell wrote: Why not email the maintainers of packages you think need a better description - ideally giving suggestions? I'd welcome that for any of my packages. +1. Of course, requiring feedback in order to improve places an undue burden on the users; the maintainers should be trying to save users from that labor. But everything has to start somewhere. Not to mention that not all users can actually help there; I'm still smarting a bit after hitting the functional lenses package and bouncing hard (even after digging out and reading the paper, which made more sense than the haddock...). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsec: non-greedy 'between'
Hey all,
Trying to match C-style comments, I have:
between (string /*) (string */) $ many anyChar
Which doesn't work, because it is equivalent (ignoring returned values) to
do {string /*; many anyChar; string */}
If the termination criterion was a single character, then I could use
noneOf or (satisfy . not), but that doesn't help here.
So... what am I missing?
Thanks in advance.
--
Scott Lawrence
signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec: non-greedy 'between'
On Sun, Sep 11, 2011 at 1:38 PM, Scott Lawrence byt...@gmail.com wrote:
Hey all,
Trying to match C-style comments, I have:
between (string /*) (string */) $ many anyChar
Which doesn't work, because it is equivalent (ignoring returned values) to
do {string /*; many anyChar; string */}
Use manyTill.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec: non-greedy 'between'
On 09/11/11 16:45, Alexander Solla wrote: Use manyTill. Ah, but of course. Thanks again! -- Scott Lawrence signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec: non-greedy 'between'
On Sunday 11 September 2011, 22:38:30, Scott Lawrence wrote:
Hey all,
Trying to match C-style comments, I have:
between (string /*) (string */) $ many anyChar
Which doesn't work, because it is equivalent (ignoring returned values)
to
do {string /*; many anyChar; string */}
If the termination criterion was a single character, then I could use
noneOf or (satisfy . not), but that doesn't help here.
So... what am I missing?
manyTill
A quick example:
Prelude Text.Parsec parse (do {spaces; string /*; com - manyTill
anyChar (string */); rmd - getInput; return (com, rmd);}) /* a
comment */ and code /* and another comment */
Right ( a comment , and code /* and another comment */)
Thanks in advance.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] matrix vector product
Hi, can anyone help me with the matrix vector product ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix vector product
Hi, repa-algorithms[1] has a nice implementation. I multiplied a 1000*1000 matrix and saw all my four cores running to the full.'Twas a beautiful moment :) There are other libraries - hmatrix for example - if you intend to have a look at the source code. regards Hemanth [1] repa-algorithms: http://hackage.haskell.org/packages/archive/repa-algorithms/2.2.0.1/doc/html/Data-Array-Repa-Algorithms-Matrix.html On Mon, Sep 12, 2011 at 8:58 AM, kolli kolli nammukoll...@gmail.com wrote: Hi, can anyone help me with the matrix vector product ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I drink I am thunk. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
