- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] [Haskell-beginners] texture mapping with SDL
by Sumit Sahrawat, Maths & Computing, IIT (BHU) 17 Apr '15

17 Apr '15

On 17 April 2015 at 19:28, Florian Gillard <florian.gillard(a)gmail.com> wrote: > Hi everyone, > > I am not sure my previous message went trough, if so, sorry for the double > post. > > I am trying to make a basic raycaster (something like the first > wolfenstein 3D) using haskell and SDL 1.2 > > So far I have it working using coloured lines and I would like to know if > there is any way to apply transforms to textures loaded in memory using > SDL, in order to achieve basic texture mapping on the walls. > > I looked at the SDL doc but I didn't find anything looking like what I > need. > > The code is there: > > https://github.com/eniac314/maze-generator/blob/master/raycaster.hs > > sreenshot here: > https://github.com/eniac314/maze-generator/blob/master/raycaster.png > > (the last part is not done yet but has nothing to do with the raycaster) > > I would appreciate any suggestion :) > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > The message got through. It might be better answered on the haskell-cafe so I'm relaying it there. -- Regards Sumit Sahrawat

1 0

Coding katas/dojos and functional programming introduction
by Gautier DI FOLCO 17 Apr '15

17 Apr '15

Hello, Some days ago I have participated to a coding dojo* which aimed to be an introduction to functional programming. I have also facilitate 3 of events like this and do several talks on this subject. But I'm kinda disappointed because each time there is a common pattern: 1. Unveil the problem which will be treated 2. Let the attendees solve it 3. Show the FP-ish solution (generally a bunch of map/fold) I think it's frustrating for the attendees (because they don't try to solve it) and gives a false illusion of knowledge. I don't consider myself as a "FP guru" or anything but for me FP is a matter of types and expressions, so when someone illustrate FP via map/fold, it's kind of irritating. Ironically, the best workshop I have done was on functional generalization (you begin by two hard coded functions, sum and product, and you extract Foldable and Monoid), but again, it's not satisfying. We can do better, we should do better. Have you got any feedback/subjet ideas/examples on how to introduce "real" FP to beginners in a short amount of time (like 1-3 hours)? Thanks in advance for your help. Regards. * Basically you have 2 to 3 hours, a problem and you try to solve with in iteration with different constraints

7 9

Ongoing IHG work to improve Hackage security
by Duncan Coutts 17 Apr '15

17 Apr '15

All, The IHG members identified Hackage security as an important issue some time ago and myself and my colleague Austin have been working on a design and implementation. The details are in this blog post: http://www.well-typed.com/blog/2015/04/improving-hackage-security We should have made more noise earlier about the fact that we're working on this. We saw that it was important to finally write this up now because other similar ideas are under active discussion and we don't want to cause too much unnecessary duplication. The summary is this: We're implementing a system to significantly improve Hackage security. It's based on a sensible design (The Update Framework) by proper crypto experts. The basic system is fully automatic and covers all packages on Hackage. A proposed extension would give further security improvements for individual packages at the cost of a modest effort from package authors. http://theupdateframework.com/ It will also allow the secure use of untrusted public Hackage mirrors, which is the simplest route to better Hackage reliability. As a bonus we're including incremental index downloads to reduce `cabal update` wait times. And it's all fully backwards compatible. I should also note that our IHG funding covers the first phase of the design, and for the second phase we would very much welcome others to get involved with the detailed design and implementation (or join the IHG and contribute further funding). -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 5

Execution order in IO
by Jon Schneider 17 Apr '15

17 Apr '15

Good morning all, I think I've got the hang of the way state is carried and fancy operators work in monads but still have a major sticky issue. With lazy evaluation where is it written that if you write things with no dependencies with a "do" things will be done in order ? Or isn't it ? Is it a feature of the language we're supposed to accept ? Is it something in the implementation of IO ? Is the do keyword more than just a syntactic sugar for a string of binds and lambdas ? Jon

14 22

Advice needed on how to improve some code
by Jeff 16 Apr '15

16 Apr '15

Hello, I am seeking some advice on how I might improve a bit of code. The function in question reads and parses part of a binary protocol, storing the parsed info as it proceeds. parseDeviceData is called by parseDevice (shown further down). It looks to me like there should be a more concise, less repetitive way to do what parseDeviceData does. Any advice on this would be greatly appreciated. parseDeviceData :: P.Payload -> Parser P.Payload parseDeviceData pl = let mdm = P.dataMask ( P.payloadData pl ) in ( let pld = P.payloadData pl in if testBit mdm ( fromEnum D.Sys ) then parseDeviceSysData >>= ( \s -> return ( pl { P.payloadData = pld { P.sysData = Just s } } ) ) else return pl ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.GPS ) then parseDeviceGPSData >>= ( \s -> return ( pl' { P.payloadData = pld { P.gpsData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.GSM ) then parseDeviceGSMData >>= ( \s -> return ( pl' { P.payloadData = pld { P.gsmData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.COT ) then parseDeviceCOTData >>= ( \s -> return ( pl' { P.payloadData = pld { P.cotData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.ADC ) then parseDeviceADCData >>= ( \s -> return ( pl' { P.payloadData = pld { P.adcData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.DTT ) then parseDeviceDTTData >>= ( \s -> return ( pl' { P.payloadData = pld { P.dttData = Just s } } ) ) else return pl' ) >>= ( \pl' -> let pld = P.payloadData pl' in if testBit mdm ( fromEnum D.OneWire ) then parseDeviceOneWireData >>= ( \s -> return ( pl' { P.payloadData = pld { P.iwdData = Just s } } ) ) else return pl' ) >>= ( \pl' -> if testBit mdm ( fromEnum D.ETD ) then parseDeviceEventData pl' else return pl' ) The Parser above is a Data.Binary.Strict.Get wrapped in a StateT, where the state is a top-level structure for holding the parsed packet. parseDevice :: Bool -> Parser () parseDevice _hasEvent = parseTimestamp >>= ( \ts -> if _hasEvent then lift getWord8 >>= ( \e -> lift getWord16be >>= ( \mdm -> return ( P.Payload "" ( Just ts ) $ P.blankDevicePayloadData { P.dataMask = mdm , P.eventID = toEnum ( fromIntegral e .&. 0x7f ) , P.deviceStatusFlag = testBit e 7 , P.hasEvent = True } ) ) ) else lift getWord16be >>= ( \mdm -> return ( P.Payload "" ( Just ts ) $ P.blankDevicePayloadData { P.dataMask = mdm } ) ) ) >>= parseDeviceData >>= ( \dpl -> get >>= ( \p -> put ( p { P.payloads = dpl : P.payloads p } ) ) ) Here are the data types for the Packet and Payload: data Payload = Payload { imei :: !BS.ByteString , timestamp :: Maybe Word64 , payloadData :: PayloadData } data PayloadData = HeartBeatPL | SMSFwdPL { smsMesg :: !BS.ByteString } | SerialPL { auxData :: !Word8 , fixFlag :: !Word8 , gpsCoord :: !GPSCoord , serialData :: !BS.ByteString } | DevicePL { hasEvent :: !Bool , deviceStatusFlag :: !Bool , eventID :: !E.EventID , dataMask :: !Word16 , sysData :: Maybe DS.SysData , gpsData :: Maybe DGP.GPSData , gsmData :: Maybe DGS.GSMData , cotData :: Maybe DC.COTData , adcData :: Maybe DA.ADCData , dttData :: Maybe DD.DTTData , iwdData :: Maybe DO.OneWireData , etdSpd :: Maybe ES.SpeedEvent , etdGeo :: Maybe EG.GeoEvent , etdHealth :: Maybe EH.HealthEvent , etdHarsh :: Maybe EHD.HarshEvent , etdOneWire :: Maybe EO.OneWireEvent , etdADC :: Maybe EA.ADCEvent } deriving ( Show ) data Packet = Packet { protocolVersion :: !Word8 , packetType :: !PT.PacketType , deviceID :: Maybe BS.ByteString , payloads :: ![ Payload ] , crc :: !Word16 } deriving ( Show ) Lastly, here is the Parser monad transformer: module G6S.Parser where import Control.Monad.State.Strict import Data.Binary.Strict.Get import qualified Data.ByteString as BS import qualified G6S.Packet as GP type Parser = StateT GP.Packet Get runParser :: Parser a -> BS.ByteString -> Maybe a runParser p bs = let ( result, _ ) = runGet ( runStateT p GP.initPacket ) bs in case result of Right tup -> Just $ fst tup Left _ -> Nothing I hope there is enough info here. Thanks, Jeff

6 10

Re: [Haskell-cafe] Ongoing IHG work to improve Hackage security
by Mikhail Glushenkov 16 Apr '15

16 Apr '15

Hi, On 16 April 2015 at 16:08, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Being historically a tape-originating archive format, `tar` does support > such destructive updates as a standard-feature by appended content. Thanks, I understand this. My question was about whether cabal-install supports this feature of tar (turns out, it does). > Using this, we can actually have *all* historic .cabal revisions in the > 00-index.tar file as hidden entries. I don't think we do this right now, though.

1 0

Re: [Haskell-cafe] Ongoing IHG work to improve Hackage security
by Duncan Coutts 16 Apr '15

16 Apr '15

On Thu, 2015-04-16 at 16:08 +0200, Herbert Valerio Riedel wrote: > On 2015-04-16 at 15:14:47 +0200, Mikhail Glushenkov wrote: > > [...] > > > Thank you, this is very exciting. But won't the post-release .cabal > > update feature interfere with "package index as an append-only log" > > concept? IIUC, right now it is implemented as a destructive update of > > the corresponding package index entry, so making the package index > > immutable will break backwards compatibility. > > Being historically a tape-originating archive format, `tar` does support > such destructive updates as a standard-feature by appended content. See > also the '--update' operation in the tar(1) man-page: > > | -u, --update > | Append files which are newer than the corresponding copy in > | the archive. Arguments have the same meaning as with -c and > | -r options. > > Using this, we can actually have *all* historic .cabal revisions in the > 00-index.tar file as hidden entries. This would in theory give > `cabal-install` access to all cabal revisions (if we'd ever want to have > a feature in cabal that requires access to previous cabal revisions) Yes, we can choose to do that. That's sort-of what I was getting at when I mentioned that you could then view the tar file as a transaction log. > I actually find Duncan's approach rather elegant, as it simply builds on > existing standard features of both .tar files and the HTTP protocol > (resuming HTTP downloads). And they don't even require any custom HTTP > server implementation to work, and there's a graceful fallback. And we > don't need to introduce a completely new protocol/tool into the mix > (such as Git, which has dump-http(s), smart-http(s), git, as > transport-layers to chose from, and has various other moving parts such > as a ~/.gitconfig that can affect how Git operates, like redirecting > clone-urls transparently, also it avoids having to handle subtle > platform-specific issues with shelling out to an external command; from > this POV the HTTP/tar approach is the more KISS-compliant one, IMHO) > > Cheers, > hvr >

1 0

Re: [Haskell-cafe] Improvements to package hosting and security
by Michael Snoyman 16 Apr '15

16 Apr '15

That could work in theory. My concern with such an approach is that- AFAIK- the tooling around that kind of stuff is not very well developed, as opposed to an approach using Git, SHA512, and GPG, which should be easy to combine. But I could be completely mistaken on this point; if existing, well vetted technology exists for this, I'm not opposed to using it. On Mon, Apr 13, 2015 at 6:04 PM Arnaud Bailly | Capital Match < arnaud(a)capital-match.com> wrote: > Just thinking aloud but wouldn't it be possible to take advantage of > cryptographic ledgers a la Bitcoin for authenticating packages and tracking > the history of change ? This would provide redundancy as the transactions > log is distributed and "naturally" create a web of trust or at least > authenticate transactions. People uploading or modifying a package would > have to sign a transactions with someone having enough karma to allow this. > > Then packages themselves could be completely and rather safely distributed > through standard p2p file sharing. > > I am not a specialist of crypto money, though. > > My 50 cts > Arnaud > > Le lundi 13 avril 2015, Dennis J. McWherter, Jr. <dennis(a)deathbytape.com> > a écrit : > >> This proposal looks great. The one thing I am failing to understand (and >> I recognize the proposal is in early stages) is how to ensure redundancy in >> the system. As far as I can tell, much of this proposal discusses the >> centralized authority of the system (i.e. ensuring secure distribution) and >> only references (with little detail) the distributed store. For instance, >> say I host a package on a personal server and one day I decide to shut that >> server down; is this package now lost forever? I do see this line: "backup >> download links to S3" but this implies that the someone is willing to pay >> for S3 storage for all of the packages. >> >> Are there plans to adopt a P2P-like model or something similar to support >> any sort of replication? Public resources like this seem to come and go, so >> it would be nice to avoid some of the problems associated with high churn >> in the network. That said, there is an obvious cost to replication. >> Likewise, the central authority would have to be updated with new, relevant >> locations to find the file (as it is currently proposed). >> >> In any case, as I said before, the proposal looks great! I am looking >> forward to this. >> >> On Monday, April 13, 2015 at 5:02:46 AM UTC-5, Michael Snoyman wrote: >>> >>> Many of you saw the blog post Mathieu wrote[1] about having more >>> composable community infrastructure, which in particular focused on >>> improvements to Hackage. I've been discussing some of these ideas with both >>> Mathieu and others in the community working on some similar thoughts. I've >>> also separately spent some time speaking with Chris about package >>> signing[2]. Through those discussions, it's become apparent to me that >>> there are in fact two core pieces of functionality we're relying on Hackage >>> for today: >>> >>> * A centralized location for accessing package metadata (i.e., the cabal >>> files) and the package contents themselves (i.e., the sdist tarballs) >>> * A central authority for deciding who is allowed to make releases of >>> packages, and make revisions to cabal files >>> >>> In my opinion, fixing the first problem is in fact very straightforward >>> to do today using existing tools. FP Complete already hosts a full Hackage >>> mirror[3] backed by S3, for instance, and having the metadata mirrored to a >>> Git repository as well is not a difficult technical challenge. This is the >>> core of what Mathieu was proposing as far as composable infrastructure, >>> corresponding to next actions 1 and 3 at the end of his blog post (step 2, >>> modifying Hackage, is not a prerequesite). In my opinion, such a system >>> would far surpass in usability, reliability, and extensibility our current >>> infrastructure, and could be rolled out in a few days at most. >>> >>> However, that second point- the central authority- is the more >>> interesting one. As it stands, our entire package ecosystem is placing a >>> huge level of trust in Hackage, without any serious way to vet what's going >>> on there. Attack vectors abound, e.g.: >>> >>> * Man in the middle attacks: as we are all painfully aware, >>> cabal-install does not support HTTPS, so a MITM attack on downloads from >>> Hackage is trivial >>> * A breach of the Hackage Server codebase would allow anyone to upload >>> nefarious code[4] >>> * Any kind of system level vulnerability could allow an attacker to >>> compromise the server in the same way >>> >>> Chris's package signing work addresses most of these vulnerabilities, by >>> adding a layer of cryptographic signatures on top of Hackage as the central >>> authority. I'd like to propose taking this a step further: removing Hackage >>> as the central authority, and instead relying entirely on cryptographic >>> signatures to release new packages. >>> >>> I wrote up a strawman proposal last week[5] which clearly needs work to >>> be a realistic option. My question is: are people interested in moving >>> forward on this? If there's no interest, and everyone is satisfied with >>> continuing with the current Hackage-central-authority, then we can proceed >>> with having reliable and secure services built around Hackage. But if >>> others- like me- would like to see a more secure system built from the >>> ground up, please say so and let's continue that conversation. >>> >>> [1] https://www.fpcomplete.com/blog/2015/03/composable- >>> community-infrastructure >>> [2] https://github.com/commercialhaskell/commercialhaskell/wiki/ >>> Package-signing-detailed-propsal >>> [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror >>> [4] I don't think this is just a theoretical possibility for some point >>> in the future. I have reported an easily trigerrable DoS attack on the >>> current Hackage Server codebase, which has been unresolved for 1.5 months >>> now >>> [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9 >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "Commercial Haskell" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to commercialhaskell%2Bunsubscribe(a)googlegroups.com. >> To post to this group, send email to commercialhaskell(a)googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae… >> <https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae…> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > *Arnaud Bailly* > > CTO | Capital Match > > CapitalMatch > > 71 Ayer Rajah Crescent | #06-16 | Singapore 139951 > > (FR) +33 617 121 978 / (SG) +65 8408 7973 | arnaud(a)capital-match.com | > www.capital-match.com > > Disclaimer: > > *Capital Match Platform Pte. Ltd. (the "Company") registered in Singapore > (Co. Reg. No. 201501788H), a subsidiary of Capital Match Holdings Pte. Ltd. > (Co. Reg. No. 201418682W), provides services that involve arranging for > multiple parties to enter into loan and invoice discounting agreements. The > Company does not provide any form of investment advice or recommendations > regarding any listings on its platform. In providing its services, the > Company's role is limited to an administrative function and the Company > does not and will not assume any advisory, fiduciary or other duties to > clients of its services.* > >

8 24

FunDeps and type inference
by Olaf Klinke 15 Apr '15

15 Apr '15

Dear cafe, I want to write an evaluation function that uncurries its function argument as necessary. Examples should include: eval :: (a -> b) -> a -> b eval :: (a -> b -> c) -> a -> (b -> c) eval :: (a -> b -> c) -> (a,b) -> c and hence have both eval (+) 4 5 eval (+) (4,5) typecheck. My approach is to use a type class: class Uncurry f a b where eval :: f -> a -> b instance Uncurry (a -> b) a b where eval = ($) instance (Uncurry f b c) => Uncurry ((->) a) f) (a,b) c where eval f (a,b) = eval (f a) b This works, but not for polymorphic arguments. One must annotate function and argument with concrete types when calling, otherwise the runtime does not know what instance to use. Type inference on ($) is able to infer the type of either of f, a or b in the expression b = f $ a if the type of two is known. Thus I am tempted to add functional dependencies class Uncurry f a b | f a -> b, a b -> f, f b -> a but I get scary errors: With only the first of the three dependencies, the coverage condition fails. Adding UndecidableInstances, the code compiles. Now type inference on the return type b works, but one can not use e.g. (+) as function argument. Adding the second dependency results in the compiler rejecting the code claiming "Functional dependencies conflict between instance declarations". I can not quite see where they would, and the compiler does not tell me its counterexample. I can see that eval max (True,False) :: Bool -- by second instance declaration, -- when max :: Bool -> Bool -> Bool eval max (True,False) :: (Bool,Bool) -> (Bool,Bool) -- by first instance declaration -- when max :: (Bool,Bool) -> (Bool,Bool) -> (Bool,Bool) but this ambiguity is precisely what the dependency a b -> f should help to avoid, isn't it? Judging by the number of coverage condition posts on this list this one is easy to get wrong and the compiler messages are not always helpful. Is this a kind problem? Would anyone care to elaborate? Thanks, Olaf

2 1

Why no Floating instance for Data.Fixed / Data.Fixed.Binary
by Douglas McClean 15 Apr '15

15 Apr '15

I'm wondering why the decision was made not to have a Floating instance for Data.Fixed. I understand that -- being a fixed point number type -- it doesn't line up with the name of the Floating typeclass. But it also seems that Floating is misnamed, because none of the functions there really have anything to do with floating point representation. This is why we still have Floating instances for, say, exact reals or symbolic numbers, neither of which has a floating point representation. It seems that the actual criterion for membership in Floating is something like "has a canonical choice for degree of approximation". Double and Float are in because we round to the nearest value. Exact reals are in because we don't have to approximate, symbolic numbers too. Rational is out because there's no clear choice of how to approximate. But by this criterion, Data.Fixed should be in. And indeed it would be useful for it to be in. If I choose to represent values from the real world by a fixed point approximation instead of a floating point approximation, shouldn't I still be able to take sines and cosines etc? Obviously I can fix this by using a newtype. I'm just curious if am I missing a reason why the current definition is more desirable? -Doug McClean

3 4