On 01/30/2013 07:27 PM, Edward Z. Yang wrote:
https://status.heroku.com/incidents/489
Unsigned Hackage packages are a ticking time bomb.
I agree this is terrible, I've started working on this, but this is
quite a bit of work and other priorities always pop up.
On 01/30/2013 10:48 PM, Niklas Hambüchen wrote:
You are right, I skipped over that this was actually a server-side
exploit - sure, end-to-end signing will help here.
it helps also in the HTTP case; a MiTM wouldn't be able to change the
package without knowing the private key.
more to the point
Ertugrul Söylemez e...@ertes.de writes:
People are using Hackage!
+1. And I keep telling people to use it. Sure, it'd be better if they
used .debs, .rpms, or whatever goes on Mac and Windows. But that would
mean I would need to build those packages, including maintaining systems
with the
Hi,
Am Mittwoch, den 30.01.2013, 15:07 -0800 schrieb Edward Z. Yang:
Nevertheless, I believe we are in violent agreement that
cryptographically signed Hackage packages should happen as soon as
possible!
I don’t think we need hackage support here. Just add a MD5-Sum: field
to the .cabal file
Casey Basichis caseybasic...@gmail.com wrote:
I'm not entirely sure what you mean.
I'm intending on using Ogre for GUI - for which there is the Hogre
bindings, but after emailing the DEV about it, I didn't get the
impression from his advice that I should be using it for production
code.
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
In any case there is no valid excuse for the lack of crypto. It's too
easy to attack Hackage, so we need some crypto regardless of what we
interpret it as.
My proposal is:
1. Build the necessary machinery into Cabal to allow signing keys and
On 01/31/2013 08:16 AM, Ketil Malde wrote:
*MY* proposal is that:
0. Hackage sends an email to the previous uploader whenever a new
version of a package is uploaded by somebody else.
At least that way, I would be notified if it happened to my packages,
and I would be able to check up on
Quoth Casey Basichis caseybasic...@gmail.com,
...
I am using several other C++ libraries for which there are no existing
bindings and no Haskell alternative packages that are even remotely
close.
Are you suggesting it would be better to write all my own FFI bindings
for all the needed
Vincent Hanquez t...@snarc.org wrote:
I agree this is terrible, I've started working on this, but this is
quite a bit of work and other priorities always pop up.
https://github.com/vincenthz/cabal
https://github.com/vincenthz/cabal-signature
My current implementation generate a manifest
Vincent Hanquez t...@snarc.org wrote:
For example, previous maintainer might be away from email for a long
time potentially leaving a trojan version for days/weeks, or changed
email address..
And that may even be more harmful, because an insecure system with a
false sense of security is worse
Hi Ertugrul,
Thank you for the detailed reply. From what you wrote, partial FFI still
seems like the way to go.
Unfortunately Ogre isn't the only large library I'm using, so difficult
several times over sounds like a good way to handicap the project early on.
I'm perfectly happy to use Haskell
Hi Ertugrul,
Thank you for the detailed reply. From what you wrote, partial FFI still
seems like the way to go.
Unfortunately Ogre isn't the only large library I'm using, so difficult
several times over sounds like a good way to handicap the project early on.
I'm perfectly happy to use Haskell
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
In any case there is no valid excuse for the lack of crypto. It's too
easy to attack Hackage, so we need some crypto regardless of what we
interpret it as.
My proposal
On Thu, Jan 31, 2013 at 8:16 AM, Ketil Malde ke...@malde.org wrote:
Ertugrul Söylemez e...@ertes.de writes:
People are using Hackage!
+1. And I keep telling people to use it. Sure, it'd be better if they
used .debs, .rpms, or whatever goes on Mac and Windows. But that would
mean I
Thanks for replies guys. I indeed didn't notice that there are monads and
applicatives used in
this parser. My thought that monadic parsers are more verbose came from
Hutton's paper where the
code is definitely less readable than in example I provided.
There is one more thing that bothers me.
Hello,
I have found the Conduit abstraction to be very well suited to a set of
problems I am facing. I am however wondering how to implement
branching conduits, and even conduit pools.
I am currently in the process of rewriting parts (the simple parts) of
the Logstash tool. There
Joachim Breitner m...@joachim-breitner.de wrote:
And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.
Let's do it properly.
but don’t overengineer it either. Simply adding to hackage the
possibility to
Jan Stolarek jan.stola...@p.lodz.pl wrote:
Thanks for replies guys. I indeed didn't notice that there are monads
and applicatives used in this parser. My thought that monadic parsers
are more verbose came from Hutton's paper where the code is definitely
less readable than in example I
On Wed, Jan 30, 2013 at 1:21 PM, Jan Stolarek wrote:
I will be writing a parser in Haskell and I wonder how to approach the
problem.
Utrecht University has a course that covers this, among other things. You
might find the slides and lecture notes useful:
On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:
Joachim Breitner m...@joachim-breitner.de wrote:
And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.
Let's do it properly.
but don’t overengineer it either.
From my experience, these things are needed to get solid (i.e. not flaky
software) results.
This is not what normal Haskell bindings look like though:
1. Create an interface over the Haskell RTS if you are going to use any of
it from C++, and use dependency injection to choose between mock and
On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
In any case there is no valid excuse for the lack of crypto. It's too
easy to attack Hackage, so we need some crypto
Vincent Hanquez t...@snarc.org wrote:
That was exactly my suggestion actually. It requires the ability to
make and check signatures. The making can be done with external
tools like GnuPG, but the checking has to be done by cabal-install.
To detect changed keys there also needs to be a
On 31/01/13 09:16, Ketil Malde wrote:
*MY* proposal is that:
0. Hackage sends an email to the previous uploader whenever a new
version of a package is uploaded by somebody else.
At least that way, I would be notified if it happened to my packages,
and I would be able to check up on the
I'm an Italian IT teacher and I would like to introduce functional
programming using haskell.
As classroom activity, I would like to build-up a simple fuzzy inference
engine.
Does anyone know if someone has experience in teaching haskell to high
school students or something has already been done
You can get the paper here for free:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.1464
On Thu, Jan 31, 2013 at 12:02 PM, claudio wbig...@gmail.com wrote:
I'm an Italian IT teacher and I would like to introduce functional
programming using haskell.
As classroom activity, I
On Thu, Jan 31, 2013 at 11:48 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote:
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote:
In any case there is no valid excuse for the
Vincent Hanquez t...@snarc.org writes:
On 01/31/2013 08:16 AM, Ketil Malde wrote:
At least that way, I would be notified if it happened to my packages,
and I would be able to check up on the situation, and rectify it.
you wouldn't in real cases,
I wouldn't what? Be notified? Rectify
On Thu, Jan 31, 2013 at 11:40 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote:
Joachim Breitner m...@joachim-breitner.de wrote:
And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure
Ertugrul Söylemez e...@ertes.de writes:
And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.
Yes. As is clear to all, the current low level of security means that
nobody are _actually_ downloading stuff of
On Thu, Jan 31, 2013 at 12:53 PM, Ketil Malde ke...@malde.org wrote:
Ertugrul Söylemez e...@ertes.de writes:
And that may even be more harmful, because an insecure system with a
false sense of security is worse than an insecure system alone.
Yes. As is clear to all, the current low
On Thu, Jan 31, 2013 at 11:11 AM, Casey Basichis caseybasic...@gmail.comwrote:
Hi,
I'm working on a project in Haskell and C++ where the former is the brains
and the latter is for UI, interaction etc.
I've read this
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and
On Thu, Jan 31, 2013 at 11:48 AM, Simon Marechal si...@banquise.net wrote:
Hello,
I have found the Conduit abstraction to be very well suited to a
set of
problems I am facing. I am however wondering how to implement
branching conduits, and even conduit pools.
I am
Dnia czwartek, 31 stycznia 2013, Ertugrul Söylemez napisał:
Remember that 'Either e' is also a monad. =)
I remember - this makes the change from Maybe to Either very easy :) Still I
found that adding
error message to every combinator and function ads a lot of boilerplate. Also,
I experince
On 31/01/2013 13:50, Michael Snoyman wrote:
* To simplify, we start off with a call to injectLeftovers. This means
that we can entirely ignore the Leftover constructor in the main function.
* Since a Sink will never yield values, we can also ignore the
HaveOutput constructor.
* As soon as
Hi Cafe,
I try to implement little typed DSL with functions, but there is a problem:
compiler is unable to infer type for my functions. It seems that context
is clear, but still GHC complains Could not deduce
It is sad because without type inference the DSL will be very difficult to
use.
Dear Haskellers,
for all who are located near Frankfurt, there is a new Meetup kicked
off: http://www.meetup.com/Frankfurt-Haskell-User-Group
regards
Peter Althainz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I am working with bulk sources and sinks, that is with a type like:
Source m [a]
Sink [a] m ()
The problem is that I would like to work on individual values in my
conduit. I can have this:
concat :: (Monad m) = Conduit [a] m a
concat = awaitForever (mapM_ yield)
But how can I do it the other
Hi Dmitry.
I try to implement little typed DSL with functions, but there is a problem:
compiler is unable to infer type for my functions. It seems that context
is clear, but still GHC complains Could not deduce
It is sad because without type inference the DSL will be very difficult to
Hello, Simon.
On 31 January 2013 17:24, Simon Marechal si...@banquise.net wrote:
On 31/01/2013 13:50, Michael Snoyman wrote:
* To simplify, we start off with a call to injectLeftovers. This means
that we can entirely ignore the Leftover constructor in the main function.
* Since a Sink will
Andres, thank you!
Your response is really helpful. I will try to adopt your suggestion.
Thank again!
Dmitry
On Thu, Jan 31, 2013 at 7:27 PM, Andres Löh and...@well-typed.com wrote:
Hi Dmitry.
I try to implement little typed DSL with functions, but there is a
problem:
compiler is
[We apologize if you receive multiple copies of this message.]
CALL FOR PARTICIPATION
==
8th International Workshop on
Applied and Computational Category Theory
ACCAT 2013
http://accat2013.zib.de/
Satellite Event of ETAPS 2013, Rome, March 17 2013
==
Scope
=
Since the
On 01/30/2013 08:27 PM, Edward Z. Yang wrote:
https://status.heroku.com/incidents/489
Unsigned Hackage packages are a ticking time bomb.
Somewhere else that shall not be mentioned, someone posted this link
which points to an interesting solution to this problem:
On Thu, Jan 31, 2013 at 1:31 AM, Junior White efi...@gmail.com wrote:
Hi Cafe,
I downloaded the latest hugs98 source package, unzip and build, I get
the following link errors. It seems many symbols are not defined, am I
missing same depending libraries?
I don't think anyone is maintaining
Thanks everyone, I very much appreciate your help, and I think it did help.
I've spent the last few days implementing a substantial chunk of my system
using each of two different techniques. I've ended up going with and ADT
containing functions closed over the 'thing'. This seems to be the
for your convenience, the correct link:
https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 1/30/13 7:21 AM, Jan Stolarek wrote:
I will be writing a parser in Haskell and I wonder how to approach the problem.
My first thought
was to use monadic parser, e.g. like the one described by Hutton and Meijer in
Monadic Parsing
in Haskell functional pearl. But then I stumbled upon this:
On Thu, 31 Jan 2013 12:02:12 +0100, claudio wbig...@gmail.com wrote:
I found only this page:
http://www.haskell.org/haskellwiki/AI/Logic/Fuzzy
with some information and a link to a pubblication (with fee, I didn't
download yet).
I have updated this page, the link now points to a page with
Hi,
I am trying to call a stored procedure (exec gp_somestoredproc 123,22)
using microsoft sql server 2008 R2 using hdbc-odbc.
Here is the haskell code:
import Database.HDBC
import Database.HDBC.ODBC
import Control.Monad
import Data.Maybe
import qualified Data.ByteString.Char8 as B
test1 =
Git has the ability to solve all of this.
...
2. Uploads to hackage either happen through commits to the git
repository,
or an old-style upload to hackage automatically creates a new anonymous
branch in the git repository.
3. The git repository is authorative. Signing releases, code reviews
Sadly! I like hugs because it can embed in my game client as lua. For game
logic language, I think the following properties are important:
1. Portable, works on pc,macosx,ios,android even flash or web.
2. Intepret, for quick develop, quick test.
3. Hot code load, for online bugfix.
4. Small, game
Firstly, what's the use case that you want to deal with lists? If it's for
efficiency, you'd probably be better off using a Vector instead.
But I think the inverse of `concat` is `singleton = Data.Conduit.List.map
return`, or `awaitForever $ yield . return`, using the list instance for
Monad.
On Thu, Jan 31, 2013 at 10:15 PM, Junior White efi...@gmail.com wrote:
So that lua best fits the rule very well, but i like haskell much more.
After doing some research, I find in the haskell world, there is a hugs
fits my demands. I'm sad to know that no one is maintaining hugs any more.
I
On 02/01/2013 05:21 AM, Michael Snoyman wrote:
Firstly, what's the use case that you want to deal with lists? If it's
for efficiency, you'd probably be better off using a Vector instead.
That is a good point, and I wanted to go that way, but was not sure it
would help me a lot here. My use case
On Fri, Feb 1, 2013 at 8:42 AM, Simon Marechal si...@banquise.net wrote:
On 02/01/2013 05:21 AM, Michael Snoyman wrote:
Firstly, what's the use case that you want to deal with lists? If it's
for efficiency, you'd probably be better off using a Vector instead.
That is a good point, and I
Hello,
Many texts explain the following Fibonacci code:
fibs :: [Integer]
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
But this code is very slow because evaluation of (+) is done
lazily. If we have the following strict zipWith', the code above
becomes much faster.
zipWith' f (a:as) (b:bs) = x
56 matches
Mail list logo
