[Haskell-cafe] [announce] second Haskell meetup in Paris
Hi, I am pleased to annouce that I'm bootstrapping a Haskell-enthusiastics group in Paris. We recently scheduled our second Haskell meetup in Paris. This meetup will take place next Monday (Monday, January 14, 2013). AF83 ( http://af83.com/ ) has been kind enough to offer us a room for our meeting. You don't have to, but it is recommended to, register for the meetup on http://meetup.haskell-paris.fr/ or by sending me an email. The website for our group is http://haskell-paris.fr/ (in French). You should pay it a click not only because it's written in Haskell but also to glance at our logo, propose a talk, or read the digest of past meetup(s). Regards, --Lucas DiCioccio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
On Wed, Jan 9, 2013 at 11:38 PM, Joachim Breitner m...@joachim-breitner.de wrote: Am Mittwoch, den 09.01.2013, 15:11 +0100 schrieb Erik Hesselink: We finally solved the problems by completely moving to strict map operations, strict MVar/TVar operations, and strict data types. do you mean strict by policy (i.e. before storing something in a [MT]Var, you ensure it is evaluated) or by construction (by `seq` or `deepseq`’ing everything before it is stored)? In the latter case: Seq or deeqseq? Again in the latter case: Do you worry about the performance of repeatedly deepseq’ing an already deepseq’ed and possibly large value? Strict by construction: we `seq` when storing in a var. This is similar to the primed functions in some places, and the new Data.Map.Strict. So repeatedly deepseq'ing isn't a problem: deepseq in our case is only used for debugging. You are not the first user of Haskell who ends up with that approach to lazy evaluation. I’m not sure what that means for Haskell, though. Well, we still use the 'normal' lazy approach in most places. Only where we have persistent shared state do we use the above approach of making everything strict. This means updaters pay the computational price, not readers, which seems like a sane idea. Regards, Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Permanent Academic Positions (Computational Logic/Functional Programming) in Dundee Deadline 23 January
** Dundee Fellowships ** http://www.dundee.ac.uk/dundeefellows/ University of Dundee announces several permanent positions, with a 5-year starting period of a Research Fellowship. One of the named priority areas is Computational Logic/ Functional Programming / Verification. For more details, see below or email me: Katya Komendantskaya ka...@computing.dundee.ac.uk School of Computing University of Dundee Dundee Fellowship Permanent position Closing Date for applications: Wednesday 23 January 2013. University of Dundee is advertising a series of permanent academic jobs across the College of Arts Science and Engineering, named Dundee Fellows. The aim is to bring in a series of excellent academics onto permanent contracts (subject to the completion of 3 year probation) into any research area within the College. These staff will be labelled as Dundee Fellows during their first 5 years, over which time they will receive enhanced staff development and a research focus to their duties, while automatically moving to a regular academic contract (lecturer, senior lecturer, reader or professor) at the end of these 5 years. These will be independent researchers (and not postdocs under supervision). Their teaching load will start low, and will gradually increase over the first 5 years, to phase them into teaching. As the University of Dundee moves towards its 25 year vision of becoming Scotland’s leading University, we are actively investing in the next generation of our academic community. Our Dundee Fellows scheme offers exciting opportunities to outstanding, high potential, early career researchers of any age to establish themselves at the University of Dundee and develop towards making a full and excellent contribution to research, teaching and leadership in their chosen field. Full details are available here: http://www.dundee.ac.uk/dundeefellows/ ** ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Roshask
Hi, I want to use Haskell to program my robot using ros. I've found roshask https://github.com/acowley/roshask and I was wondering if someone on this list has experience with it and can tell me how good it is. Thanx! --Tijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Roshask
I know that it probably needs updating for Groovy. I don't think it has many users, which makes it more challenging to keep things running smoothly, but I'm willing to help any interested parties get it up and running. Anthony On Fri, Jan 11, 2013 at 4:37 PM, Tijn van der Zant robot...@gmail.com wrote: Hi, I want to use Haskell to program my robot using ros. I've found roshask https://github.com/acowley/roshask and I was wondering if someone on this list has experience with it and can tell me how good it is. Thanx! --Tijn ___ 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: crypto-pubkey: all your public key crypto algorithms belong to us.
Hi Cafe, I've recently released crypto-pubkey [1][2], which provide a comprehensive solution for public key cryptography. Most known RSA modes (PKCS15, OAEP, PSS) are supported, and there's also DSA and ElGamal signature support. Most of the code originally lived in cryptocipher, but have now been made better and safer, and support more modes. I've spend some good chunk of time adding KATs and tests, documentation, and making sure the performance was ahead of other haskell implementations. Enjoy, [1] http://hackage.haskell.org/package/crypto-pubkey-0.1.1 [2] https://github.com/vincenthz/hs-crypto-pubkey -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] Is http://hackage.haskell.org/packages/hackage.html having a challenging serving up archive.tar?
On Wed, 09 Jan 2013 20:05:07 +0100, KC kc1...@gmail.com wrote: :) I can't download it either. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
Hi, Am Freitag, den 11.01.2013, 23:55 +0100 schrieb Vincent Hanquez: I've recently released crypto-pubkey [1][2], which provide a comprehensive solution for public key cryptography. Most known RSA modes (PKCS15, OAEP, PSS) are supported, and there's also DSA and ElGamal signature support. Most of the code originally lived in cryptocipher, but have now been made better and safer, and support more modes. I've spend some good chunk of time adding KATs and tests, documentation, and making sure the performance was ahead of other haskell implementations. nice. But in the interest of possible users: Is there a reason why this code could not live in cryptocipher? Do we need multiple implementations of the cyphers, and expect our users to find out for themselves why to use one or the other? 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] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
On 01/11/2013 11:34 PM, Joachim Breitner wrote: nice. But in the interest of possible users: Is there a reason why this code could not live in cryptocipher? Do we need multiple implementations of the cyphers, and expect our users to find out for themselves why to use one or the other? The duplicate implementations in cryptocipher have been marked as deprecated and will be removed in a near future. The only reason is has been spun off is that i think it was a mistake to put it along block and stream cipher in the first place, and i prefer smaller package with dedicated dependencies. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
