Re: [Haskell-cafe] Streaming bytes and performance
On 03/20/2013 12:47 AM, Branimir Maksimovic wrote: Your problem is that main_6 thunks 'i' and 'a' . If you write (S6 !i !a) - get than there is no problem any more... Nope :( Unfortunately that doesn't change anything. Still allocating... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?
Hello Jeremy, I'd also like to see GHC compiling for ARM bare metal. Honestly speaking I've avoided Raspberry Pi, but rather settled on ARMv7. Side note: BeagleBone is excellent for this as you get all the TI supported tools together with JTAG debugging just for free from TI (including ARM compilers if you care about this) and also you get full documentation for its Sitara 335x SoC. Anyway, back to the GHC topic. I find it too invasive to go straight from POSIX/libc dependency to nothing on bare-metal. Instead of this while analyzing the situation for myself I've rather settled on POSIX RTOS which is much less weight that general purpose Linux distro and yet it provides a lot of API which makes GHC RTS porting work much easier. So as my hobby time permits I'm working on GHC port to RTEMS[1] which is a single-process, multi-threaded RTOS with POSIX API supported. On its devel mailing list you may find that Raspberry Pi BSP was already submitted for inclusion. Generally speaking, I also hope that since this work is much less invasive on GHC, it has higher chance of a merge into GHC HEAD once ready... Cheers, Karel [1]: http://www.rtems.org/ On 03/20/13 02:07 AM, Jeremy Shaw wrote: There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?
kiwamu has been targeting an arm cortex-m3 succesfully with jhc. this is a CPU with 40k of RAM running Haskell code very much on bare metal. :) John On Tue, Mar 19, 2013 at 6:07 PM, Jeremy Shaw jer...@n-heptane.com wrote: There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Streaming bytes and performance
Are you sure? I use ghc 7.6.2 (compiled with -O2) and without bang patternsfor 1million iterations it blows stack space.With bang patterns it runs in constant space , same as other version? bmaxa@maxa:~/haskell$ ./state +RTS -s5050 52,080 bytes allocated in the heap 3,512 bytes copied during GC 44,416 bytes maximum residency (1 sample(s)) 17,024 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par0.00s0.00s 0.s0.s Gen 1 1 colls, 0 par0.00s0.00s 0.0001s0.0001s INITtime0.00s ( 0.00s elapsed) MUT time0.00s ( 0.00s elapsed) GC time0.00s ( 0.00s elapsed) EXITtime0.00s ( 0.00s elapsed) Total time0.00s ( 0.00s elapsed) %GC time 0.0% (6.2% elapsed) Alloc rate0 bytes per MUT second Productivity 100.0% of total user, 0.0% of total elapsed Date: Wed, 20 Mar 2013 08:04:01 +0200 From: to.darkan...@gmail.com To: bm...@hotmail.com CC: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Streaming bytes and performance On 03/20/2013 12:47 AM, Branimir Maksimovic wrote: Your problem is that main_6 thunks 'i' and 'a' . If you write (S6 !i !a) - get than there is no problem any more... Nope :( Unfortunately that doesn't change anything. Still allocating... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi
On Tue, Mar 19, 2013 at 8:18 AM, Albert Y. C. Lai tre...@vex.net wrote: On 13-03-18 09:19 AM, Jesper Särnesjö wrote: Interestingly, running the program in GHCi with the -fno-ghci-sandbox flag, causes it to misbehave in the same way as when compiled: Then perhaps to mimic default ghci in hope of getting good results: - compile with -threaded (more candidly, link with -threaded, it does not change code generation) - in the program, deliberately move the work to a forkIO-thread I did this [1], and sure enough - it did result in a GHC-compiled program behaving like one run in GHCi: $ ghc -threaded -lglfw -framework OpenGL -fforce-recomp glfw_test_threaded.hs ./glfw_test_threaded [...] NVIDIA GeForce GT 330M OpenGL Engine I should mention that I tried both forkIO and forkOS, as well as marking the foreign imports as safe and unsafe, and, for my simple test program, the result was the same every way. This is certainly not the case in general, though, as the forkOS documentation explains [2]. I haven't yet worked out why simply moving all the work from the main thread to another (OS) thread fixes this problem. Based on what I've learned so far, that should, if anything, *prevent* things from working correctly. On that note, I did try to apply the same solution to a larger program [3], and while it did allow the GPU switch to happen properly, it also caused the program's window to become unresponsive. Like I mentioned in my earlier email, Mac OS X (or rather Cocoa) is fussy about GUI actions being run on the main thread. So, in summary, using GLFW to initialize an OpenGL context fails to trigger a GPU switch if done on the main thread, but works as expected if done on a different thread, in a Haskell program. I need to figure out *why* that is, so that I can find a way to simultaneously appease Haskell and Cocoa. Thanks for all your suggestions! -- Jesper Särnesjö http://jesper.sarnesjo.org/ [1] https://gist.github.com/sarnesjo/5151894#file-glfw_test_threaded-hs [2] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:forkOS [3] https://gist.github.com/sarnesjo/5116084#file-test-hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Streaming bytes and performance
On 03/20/2013 11:17 AM, Branimir Maksimovic wrote: Are you sure? I use ghc 7.6.2 Huh, I use 7.4.2, and if 7.6.2 can handle this I will try to switch. Not sure how to do that on ubuntu 12.10... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more
This is very cool. I've been keeping an eye on this library for a few months. Keep it on! On 19 March 2013 15:18, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Peter Althainz wrote: Dear All, I'm happy to announce release 0.2.1 of HGamer3D, the game engine with Haskell API, featuring FRP based API and FRP based GUI. The new FRP API is based on the netwire package. Currently only available on Windows: http://www.hgamer3d.org. Nice work! Of course, I have to ask: what influenced your choice of FRP library in favor of netwire instead of reactive-banana ? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Streaming bytes and performance
On 20 March 2013 11:41, Konstantin Litvinenko to.darkan...@gmail.com wrote: On 03/20/2013 11:17 AM, Branimir Maksimovic wrote: Are you sure? I use ghc 7.6.2 Huh, I use 7.4.2, and if 7.6.2 can handle this I will try to switch. Not sure how to do that on ubuntu 12.10... I always install ghcs under my home directory: wget http://www.haskell.org/ghc/dist/7.6.2/ghc-7.6.2-x86_64-unknown-linux.tar.bz2 tar -xf ghc-7.6.2-x86_64-unknown-linux.tar.bz2 cd ghc-7.6.2 configure --prefix=$HOME/ghcs/7.6.2 make install Then put $HOME/ghcs/7.6.2/bin in front of your $PATH. You could also use: hsenv --ghc=ghc-7.6.2-x86_64-unknown-linux.tar.bz2 for this: http://hackage.haskell.org/package/hsenv My colleague Jason just made a nice improvement: https://github.com/tmhedberg/hsenv/pull/22 which allows you to do: hsenv --ghc=7.6.2 which will automatically download the right ghc for your platform and install it in a new fresh environment isolated from the rest of your system. Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi
On Tue, Mar 19, 2013 at 12:19 AM, Jesper Särnesjö sarne...@gmail.com wrote: As I final note, I did learn that the GHC runtime generates SIGVTALRM signals to cause the scheduler to switch contexts. Perhaps this prevents GLFW from running properly? Looks like I'll need to brush up on my dtrace. A bit of googling turned up an thread on the glasgow-haskell-users mailing list, discussing a similar problem with using the C MySQL bindings [1]. One of the solutions mentioned there, was to disable the timer signals generated by the runtime [2]. This can be done using the -V RTS flag, described as follows in the documentation: Using a value of zero disables the RTS clock completely, and has the effect of disabling timers that depend on it: the context switch timer and the heap profiling timer. Context switches will still happen, but deterministically and at a rate much faster than normal. Disabling the interval timer is useful for debugging, because it eliminates a source of non-determinism at runtime. [3] Results: $ ghc -rtsopts -lglfw -framework OpenGL -fforce-recomp glfw_test.hs [...] $ ./glfw_test Apple Software Renderer $ ./glfw_test +RTS -V0 NVIDIA GeForce GT 330M OpenGL Engine Nice. This solution seems to work perfectly for me. Since the foreign code is allowed to run uninterrupted, the GPU switch happens, and since the GUI actions stay on the main thread, the program's window responds to keyboard and mouse input correctly. Are there any downsides to disabling the timer signal? Why does the documentation describe it primarily as a debugging aid? -- Jesper Särnesjö http://jesper.sarnesjo.org/ [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2010-September/thread.html#19140 [2] http://www.haskell.org/pipermail/glasgow-haskell-users/2010-September/019156.html [3] http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/runtime-control.html#rts-options-misc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi
On Wed, Mar 20, 2013 at 9:02 AM, Jesper Särnesjö sarne...@gmail.com wrote: This solution seems to work perfectly for me. Since the foreign code is allowed to run uninterrupted, the GPU switch happens, and since the GUI actions stay on the main thread, the program's window responds to keyboard and mouse input correctly. If that's correct, then I think you have found a bug in the GHC runtime: my understanding is that the timers should be disabled while foreign code is running, specifically to avoid confusing code that has no clue that there is another runtime involved. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more
Looks nice! I am curious as to why this is Windows only. Of the listed libraries (Ogre, CEGUI, SFML, enet, BulletPhysics, Vect, netwire) none seem to be platform specific. Regards /Johan 2013/3/20 Ivan Perez ivanperezdoming...@gmail.com: This is very cool. I've been keeping an eye on this library for a few months. Keep it on! On 19 March 2013 15:18, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Peter Althainz wrote: Dear All, I'm happy to announce release 0.2.1 of HGamer3D, the game engine with Haskell API, featuring FRP based API and FRP based GUI. The new FRP API is based on the netwire package. Currently only available on Windows: http://www.hgamer3d.org. Nice work! Of course, I have to ask: what influenced your choice of FRP library in favor of netwire instead of reactive-banana ? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Streaming bytes and performance
On 03/20/2013 11:17 AM, Branimir Maksimovic wrote: Are you sure? I use ghc 7.6.2 (compiled with -O2) and without bang patterns for 1million iterations it blows stack space. With bang patterns it runs in constant space , same as other version? Okay, I have found the root of allocation problem. It is not because of 7.4.2. If I use -auto-all it somehow change code generation and start allocating. If I remove -auto-all from command line than no allocation occurs. That really weird because now I don't know how to profile and get meaningful results :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: LearnByHaking.org
Hi cafe, I've been delaying the announcement of LearnByHacking.org as I wish to add more features, but some of you may be interested in it as is. The web app is inspired by and, to some degree, a lighter-weight clone of School of Haskell. I am currently using it as glorified blog that provides a means for collaborating with others on posts and include active code. For those unfamiliar with SoH, that is, code that users can execute with a single click and modify. There are lots of things on the TODO list, so if anybody wants to hack, please join in. Cheers, Deian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?
On Wed, Mar 20, 2013 at 08:05:04AM +0100, Karel Gardas wrote: Hello Jeremy, I'd also like to see GHC compiling for ARM bare metal. Honestly speaking I've avoided Raspberry Pi, but rather settled on ARMv7. Side note: BeagleBone is excellent for this as you get all the TI supported tools together with JTAG debugging just for free from TI (including ARM compilers if you care about this) and also you get full documentation for its Sitara 335x SoC. Anyway, back to the GHC topic. I find it too invasive to go straight from POSIX/libc dependency to nothing on bare-metal. Instead of this while analyzing the situation for myself I've rather settled on POSIX RTOS which is much less weight that general purpose Linux distro and yet it provides a lot of API which makes GHC RTS porting work much easier. So as my hobby time permits I'm working on GHC port to RTEMS[1] which is a single-process, multi-threaded RTOS with POSIX API supported. On its devel mailing list you may find that Raspberry Pi BSP was already submitted for inclusion. Generally speaking, I also hope that since this work is much less invasive on GHC, it has higher chance of a merge into GHC HEAD once ready... This is exactly what I've been telling my colleagues (who like me mostly are stuck working with C on embedded devices) is what we *really* ought to be doing. :) Is there anything I can do to help out? Are you doing this work in the open? Can I find the code somewhere? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extracting exposed modules from an installed library
Hi, Am Mittwoch, den 20.03.2013, 00:34 +0100 schrieb Corentin Dupont: Hi Cafe! I'm looking for how to extract the exposed modules (as a list of strings) from an installed library, giving the library name. I can see some structures in Cabal (InstalledPackageInfo) and some functions in ghc-pkg.hs in GHC, but nothing readily useable... $ ghc-pkg field base exposed-modules exposed-modules: Foreign.Concurrent GHC.Arr GHC.Base GHC.Char GHC.Conc GHC.Conc.IO GHC.Conc.Signal GHC.Conc.Sync GHC.ConsoleHandler GHC.Constants GHC.Desugar GHC.Enum GHC.Environment GHC.Err GHC.Exception GHC.Exts GHC.Fingerprint GHC.Fingerprint.Type GHC.Float GHC.Float.ConversionUtils GHC.Float.RealFracMethods GHC.Foreign GHC.ForeignPtr GHC.Generics GHC.GHCi GHC.Handle GHC.IO GHC.IO.Buffer GHC.IO.BufferedIO GHC.IO.Device GHC.IO.Encoding GHC.IO.Encoding.CodePage GHC.IO.Encoding.Failure GHC.IO.Encoding.Iconv GHC.IO.Encoding.Latin1 GHC.IO.Encoding.Types GHC.IO.Encoding.UTF16 GHC.IO.Encoding.UTF32 GHC.IO.Encoding.UTF8 GHC.IO.Exception GHC.IO.FD GHC.IO.Handle GHC.IO.Handle.FD GHC.IO.Handle.Internals GHC.IO.Handle.Text GHC.IO.Handle.Types GHC.IO.IOMode GHC.IOArray GHC.IOBase GHC.IORef GHC.IP GHC.Int GHC.List GHC.MVar GHC.Num GHC.PArr GHC.Pack GHC.Ptr GHC.Read GHC.Real GHC.ST GHC.Stack GHC.Stats GHC.Show GHC.Stable GHC.Storable GHC.STRef GHC.TypeLits GHC.TopHandler GHC.Unicode GHC.Weak GHC.Word System.Timeout GHC.Event Control.Applicative Control.Arrow Control.Category Control.Concurrent Control.Concurrent.Chan Control.Concurrent.MVar Control.Concurrent.QSem Control.Concurrent.QSemN Control.Concurrent.SampleVar Control.Exception Control.Exception.Base Control.Monad Control.Monad.Fix Control.Monad.Instances Control.Monad.ST Control.Monad.ST.Safe Control.Monad.ST.Unsafe Control.Monad.ST.Lazy Control.Monad.ST.Lazy.Safe Control.Monad.ST.Lazy.Unsafe Control.Monad.ST.Strict Control.Monad.Zip Data.Bits Data.Bool Data.Char Data.Complex Data.Dynamic Data.Either Data.Eq Data.Data Data.Fixed Data.Foldable Data.Function Data.Functor Data.HashTable Data.IORef Data.Int Data.Ix Data.List Data.Maybe Data.Monoid Data.Ord Data.Ratio Data.STRef Data.STRef.Lazy Data.STRef.Strict Data.String Data.Traversable Data.Tuple Data.Typeable Data.Typeable.Internal Data.Unique Data.Version Data.Word Debug.Trace Foreign Foreign.C Foreign.C.Error Foreign.C.String Foreign.C.Types Foreign.ForeignPtr Foreign.ForeignPtr.Safe Foreign.ForeignPtr.Unsafe Foreign.Marshal Foreign.Marshal.Alloc Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Safe Foreign.Marshal.Utils Foreign.Marshal.Unsafe Foreign.Ptr Foreign.Safe Foreign.StablePtr Foreign.Storable Numeric Prelude System.Console.GetOpt System.CPUTime System.Environment System.Exit System.IO System.IO.Error System.IO.Unsafe System.Info System.Mem System.Mem.StableName System.Mem.Weak System.Posix.Internals System.Posix.Types Text.ParserCombinators.ReadP Text.ParserCombinators.ReadPrec Text.Printf Text.Read Text.Read.Lex Text.Show Text.Show.Functions Unsafe.Coerce Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata 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
[Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
This thought isn't really related to Haskell specifically but it's more towards FP ideal in general. I'm new to the FP world and to get me started, I began reading a few papers. One paper is by John Backus called Can Programming Be Liberated from the von Neumann Style? A Functional Style and It's Algebra of Programs. While I like the premise which notes the limitation of the von Neumann Architecture, his solution to this problem makes me feel queasy when I read it. For me personally, one thing I enjoy about a typical procedural program is that it allows me to Brute Force Learn. This means I stare at a particular section of the code for a while until I figure out what it does. I may not know the reasoning behind it but I can have a pretty decent idea of what it does. If I'm lucky, later on someone may tell me oh, that just did a gradient of such and such matrix. In a way, I feel happy I learned something highly complex without knowing I learned something highly complex. Backus seems to throw that out the window. He introduces major new terms which require me to break out the math book which then requires me to break out a few other books to figure out which bases things using archaic symbols which then requires me to break out the pen and paper to mentally expand what in the world that does. It makes me feel CISCish except without a definition book nearby. It's nice if I already knew what a gradient of such and such matrix is but what happens if I don't? For the most part, I like the idea that I have the option of Brute Force Learning my way towards something. I also like the declarative aspect of languages such as SQL which let's me asks the computer of things once I know the meaning of what I'm asking. I like the ability to play and learn but I also like the ability to declare this or that once I do learn. From Backus paper, if his world comes to a reality, it seems like I should know what I'm doing before I even start. The ability to learn while coding seems to have disappeared. In a way, if the von Neumann bottleneck wasn't there, I'm not sure programming would be as popular as it is today. Unfortunately, I'm still very new and quite ignorant about Haskell so I do not know how much of Backus is incorporated in Haskell but so far, in the start of my FP learning adventure, this is how things seem to be seen. If I may generously ask, where am I wrong and where am I right with this thought? Thank you for any explanation P.S. If anyone knows of a better place I can ask this question, please feel free to show me the way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
I made an error. I meant FP to stand for Functional Programming, the concept not the language. On Wed, Mar 20, 2013 at 6:54 PM, OWP owpmail...@gmail.com wrote: This thought isn't really related to Haskell specifically but it's more towards FP ideal in general. I'm new to the FP world and to get me started, I began reading a few papers. One paper is by John Backus called Can Programming Be Liberated from the von Neumann Style? A Functional Style and It's Algebra of Programs. While I like the premise which notes the limitation of the von Neumann Architecture, his solution to this problem makes me feel queasy when I read it. For me personally, one thing I enjoy about a typical procedural program is that it allows me to Brute Force Learn. This means I stare at a particular section of the code for a while until I figure out what it does. I may not know the reasoning behind it but I can have a pretty decent idea of what it does. If I'm lucky, later on someone may tell me oh, that just did a gradient of such and such matrix. In a way, I feel happy I learned something highly complex without knowing I learned something highly complex. Backus seems to throw that out the window. He introduces major new terms which require me to break out the math book which then requires me to break out a few other books to figure out which bases things using archaic symbols which then requires me to break out the pen and paper to mentally expand what in the world that does. It makes me feel CISCish except without a definition book nearby. It's nice if I already knew what a gradient of such and such matrix is but what happens if I don't? For the most part, I like the idea that I have the option of Brute Force Learning my way towards something. I also like the declarative aspect of languages such as SQL which let's me asks the computer of things once I know the meaning of what I'm asking. I like the ability to play and learn but I also like the ability to declare this or that once I do learn. From Backus paper, if his world comes to a reality, it seems like I should know what I'm doing before I even start. The ability to learn while coding seems to have disappeared. In a way, if the von Neumann bottleneck wasn't there, I'm not sure programming would be as popular as it is today. Unfortunately, I'm still very new and quite ignorant about Haskell so I do not know how much of Backus is incorporated in Haskell but so far, in the start of my FP learning adventure, this is how things seem to be seen. If I may generously ask, where am I wrong and where am I right with this thought? Thank you for any explanation P.S. If anyone knows of a better place I can ask this question, please feel free to show me the way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package show needs QuickCheck2.6?
The mueval build issue should be taken care of in a patch I just sent the maintainer which removes 'show' as a dependency. I believe the 'show' package itself is currently in a maintainer-less state, but I don't mind taking it over. It makes sense to do so since I am also taking over lambdabot, which used to contain show in the same source tree. If there are no objections, I'll do so and probably remove the QuickCheck dependency entirely. It's used in the ShowQ module, which is really a part of lambdabot's check plugin and should be moved to lambdabot. -- James On Mar 19, 2013, at 3:18 PM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Hi, I noticed that compilation of mueval (recent: 0.8.2) breaks because show (0.5) cannot be built: it seems the type of Failure changed in QuickCheck (from 2.5 to 2.6). The build succeeds with --constraint 'QuickCheck2.6' . ___ 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] Maintaining lambdabot
On Mar 15, 2013, at 5:33 PM, Jason Dagit dag...@gmail.com wrote: I was going to start making these changes and I noticed that it doesn't currently build with ghc 7.4.1 w/Haskell Platform: https://travis-ci.org/dagit/lambdabot/builds/5541375 Do you know if the constraints on: regex-posix-0.95.1 regex-compat-0.95.1 Need to be what they are? Could we relax them without breaking anything? I've relaxed those, along with many others that I think were unnecessarily strict, and it now builds on travis: https://travis-ci.org/mokus0/lambdabot/builds/5674142 -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
Reading papers might not be the best way to get started with Haskell. It'll be a great way to expand your knowledge later, but they're generally not written to give the reader an introduction to functional programming. I highly recommend Learn You A Haskell [1]. It is extremely well written. Regards, - Clark [1] http://learnyouahaskell.com On Wed, Mar 20, 2013 at 6:59 PM, OWP owpmail...@gmail.com wrote: I made an error. I meant FP to stand for Functional Programming, the concept not the language. On Wed, Mar 20, 2013 at 6:54 PM, OWP owpmail...@gmail.com wrote: This thought isn't really related to Haskell specifically but it's more towards FP ideal in general. I'm new to the FP world and to get me started, I began reading a few papers. One paper is by John Backus called Can Programming Be Liberated from the von Neumann Style? A Functional Style and It's Algebra of Programs. While I like the premise which notes the limitation of the von Neumann Architecture, his solution to this problem makes me feel queasy when I read it. For me personally, one thing I enjoy about a typical procedural program is that it allows me to Brute Force Learn. This means I stare at a particular section of the code for a while until I figure out what it does. I may not know the reasoning behind it but I can have a pretty decent idea of what it does. If I'm lucky, later on someone may tell me oh, that just did a gradient of such and such matrix. In a way, I feel happy I learned something highly complex without knowing I learned something highly complex. Backus seems to throw that out the window. He introduces major new terms which require me to break out the math book which then requires me to break out a few other books to figure out which bases things using archaic symbols which then requires me to break out the pen and paper to mentally expand what in the world that does. It makes me feel CISCish except without a definition book nearby. It's nice if I already knew what a gradient of such and such matrix is but what happens if I don't? For the most part, I like the idea that I have the option of Brute Force Learning my way towards something. I also like the declarative aspect of languages such as SQL which let's me asks the computer of things once I know the meaning of what I'm asking. I like the ability to play and learn but I also like the ability to declare this or that once I do learn. From Backus paper, if his world comes to a reality, it seems like I should know what I'm doing before I even start. The ability to learn while coding seems to have disappeared. In a way, if the von Neumann bottleneck wasn't there, I'm not sure programming would be as popular as it is today. Unfortunately, I'm still very new and quite ignorant about Haskell so I do not know how much of Backus is incorporated in Haskell but so far, in the start of my FP learning adventure, this is how things seem to be seen. If I may generously ask, where am I wrong and where am I right with this thought? Thank you for any explanation P.S. If anyone knows of a better place I can ask this question, please feel free to show me the way. ___ 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] Haskell Weekly News: Issue 263
Welcome to issue 263 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of March 10 to 16, 2013. Quotes of the Week * shachaf: Did someone give edwardk a committee bit? Top Reddit Stories * Restored: the Haskell mailing list archives: 1990-2000. The lost books of Haskell Domain: code.haskell.org, Score: 71, Comments: 9 On Reddit: [1] http://goo.gl/wYs4E Original: [2] http://goo.gl/1Hw4G * Dependently Typed Functional Programming with Idris [video] Domain: vimeo.com, Score: 49, Comments: 20 On Reddit: [3] http://goo.gl/RDII5 Original: [4] http://goo.gl/AmmPJ * Snake game in Haskell Domain: self.haskell, Score: 48, Comments: 19 On Reddit: [5] http://goo.gl/HssiG Original: [6] http://goo.gl/HssiG * A simple graphical notation for lambda calculus Domain: binarylambda.blogspot.com, Score: 46, Comments: 35 On Reddit: [7] http://goo.gl/I3xqp Original: [8] http://goo.gl/sY6gl * Simon Peyton Jones on Adventures with types (Functional Programming eXchange 2013) Domain: skillsmatter.com, Score: 46, Comments: 27 On Reddit: [9] http://goo.gl/wUvon Original: [10] http://goo.gl/XCWsE * Guide to GHC Extensions (just some simple ones for now, will expand over time) - School of Haskell Domain: fpcomplete.com, Score: 42, Comments: 25 On Reddit: [11] http://goo.gl/XhFK5 Original: [12] http://goo.gl/Wa0K3 * layers-0.1: Modular type class machinery for monad transformer stacks. Domain: hackage.haskell.org, Score: 37, Comments: 30 On Reddit: [13] http://goo.gl/nkimL Original: [14] http://goo.gl/HFBxI * Type Families and Pokemon: School of Haskell Pick of the Week Domain: fpcomplete.com, Score: 35, Comments: 3 On Reddit: [15] http://goo.gl/mITH3 Original: [16] http://goo.gl/oymkn * Gale: an IDE for creating games in Haskell Domain: youtube.com, Score: 31, Comments: 4 On Reddit: [17] http://goo.gl/2k28x Original: [18] http://goo.gl/9SxFS * What is the best way to make a simple web service in Haskell? Domain: self.haskell, Score: 31, Comments: 34 On Reddit: [19] http://goo.gl/sVAe7 Original: [20] http://goo.gl/sVAe7 * Wadler's Blog: Informatics 1: Functional Programming Domain: wadler.blogspot.ro, Score: 25, Comments: 3 On Reddit: [21] http://goo.gl/70Ocg Original: [22] http://goo.gl/z4b38 * Constructions on Typeclasses, Part 1: F-Algebras Domain: lukepalmer.wordpress.com, Score: 24, Comments: 0 On Reddit: [23] http://goo.gl/qGsVj Original: [24] http://goo.gl/s947R * cabal-dev updated on hackage Domain: haskell.org, Score: 24, Comments: 37 On Reddit: [25] http://goo.gl/LUOQZ Original: [26] http://goo.gl/nMut4 * monoid-subclasses: ListLike-like, only built on sound theoretical foundations Domain: hackage.haskell.org, Score: 22, Comments: 24 On Reddit: [27] http://goo.gl/gA46h Original: [28] http://goo.gl/4QOKw * Introduction to Concurrent Haskell - Simon Marlow [FP Days Cambridge 2012] Domain: infoq.com, Score: 22, Comments: 1 On Reddit: [29] http://goo.gl/CS0xV Original: [30] http://goo.gl/TrVo9 Top StackOverflow Questions * Proposal for local data declarations / instances votes: 15, answers: 1 Read on SO: [31] http://goo.gl/VCd4K * What is the equivalent Haskell type for C99 bool when using FFI? votes: 14, answers: 2 Read on SO: [32] http://goo.gl/mm3hC * Disadvantages of using INLINABLE pragma votes: 13, answers: 1 Read on SO: [33] http://goo.gl/zxnBu * How to compare two lists in Haskell? votes: 11, answers: 4 Read on SO: [34] http://goo.gl/kTXqL * Haskell space usage compile time restrictions votes: 11, answers: 2 Read on SO: [35] http://goo.gl/vy7wO * haskell - Average floating point error using QuickCheck votes: 10, answers: 1 Read on SO: [36] http://goo.gl/MNsnL * Trying to understand function application operator in Haskell votes: 9, answers: 1 Read on SO: [37] http://goo.gl/ymFv4 * Haskell equivalent to Scala's groupBy votes: 9, answers: 4 Read on SO: [38] http://goo.gl/0uceW * (Num a) vs Integer type inference votes: 9, answers: 3 Read on SO: [39] http://goo.gl/N3CWn Until next time, +Daniel Santa Cruz References 1. http://code.haskell.org/~dons/haskell-1990-2000/ 2. http://www.reddit.com/r/haskell/comments/1aescj/restored_the_haskell_mailing_list_archives/ 3. http://vimeo.com/61576198 4. http://www.reddit.com/r/haskell/comments/1a7rbk/dependently_typed_functional_programming_with/ 5. http://www.reddit.com/r/haskell/comments/1a12vg/snake_game_in_haskell/ 6. http://www.reddit.com/r/haskell/comments/1a12vg/snake_game_in_haskell/ 7. http://binarylambda.blogspot.com/2013/03/lambda-diagrams-lambda-diagrams-few.html
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
On 13-03-20 06:54 PM, OWP wrote:
For me personally, one thing I enjoy about a typical procedural program
is that it allows me to Brute Force Learn.
[...]
1. I believe that you can also stare at functional programs and figure
out as much as what you can with procedural programs.
It only requires knowing the language and the libraries. And you can no
longer argue that functional languages are more declarative or higher
level than procedural languages. Once upon a time, it was true, with
parametricity, algebraic data types, higher-order functions, and list
comprehensions; now procedural languages have them too or competitive
alternatives.
2. I doubt how much you can learn from staring, be it functional
programs or procedural programs.
I posit that at most you're just reading aloud in your native tongue how
to execute the program. But then you're just competing with a computer
at its job. You barely know what requirement the program satisfies, much
less why the program satisfies that requirement.
(With the exception that the program contains no iteration or recursion,
or contains just boring iteration or recursion such as walking over an
array.)
I do not mean that you lack jargons like gradient and matrix, no.
You can explain in your own words, if you know the right idea but just
not the jargon. I am positing this: apart from telling me how to execute
the program, you cannot explain the purpose of the program, not even in
your own words, because you do not know.
Here is an example I learned recently. It is ingenious.
Let A, B be arrays of the same length N. Their elements are numbers.
They use 0-based indexing. They are the input.
int h=0, i=0, j=0;
bool answer;
while (hN iN jN) {
int Aih = A[(i+h) % N], Bjh = B[(j+h) % N];
if (Aih == Bjh) {
h = h + 1;
} else if (Aih Bjh) {
i = i + h + 1;
h = 0;
} else { /* Aih Bjh */
j = j + h + 1;
h = 0;
}
}
answer = (h = N);
answer is the output. What does answer say about the input?
The algorithm is no different in Haskell (it makes me use lowercase a,
b, n):
answer = go 0 0 0
go h i j =
if hn in jn then
case compare (a!((i+h) `mod` n)) (b!((j+h) `mod` n)) of
EQ - go (h+1) i j
GT - go 0 (i+h+1) j
LT - go 0 i (j+h+1)
else h=n
3. I completely refuse to believe that you literally do not know what
you're doing before you start.
If it were true, it must be like this: You throw dice 500 times to
generate a 500-character file. If the compiler doesn't like it, you
throw dice more times to decide what to mutate in that file. Eventually
the compiler surrenders. Now, and only now, you stare at the file for a
few minutes, and discover: it implements doubly linked list! It will be
useful when you write your own web browser later, it can help provide
the back button and the forward button...
No, it has to be the other way round. You have to decide to attempt a
web browser project or whatever in the first place. You are vague about
details, what not to include, what to include, how to do them... but you
know vaguely it's a web browser. After some time, you have to decide
which part, however small, you start to code up. Maybe you decide to
code up a doubly linked list first. Now you type up something. You type
up something knowing that the short term goal is doubly linked list, and
the long term goal is some kind of web browser or whatever project it
is. This much you know. And while you type, every key you type you
strive to get closer to a doubly linked list in good faith. Maybe
sometimes you're creative, maybe sometimes you make mistakes, maybe you
write clever code and I can't understand it, but it is not random
typing, you know the purpose, you have reasons, you understand, and you
don't just stare.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: bytestring-lexing 0.4.2
-- bytestring-lexing 0.4.2 The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -- Changes (since 0.4.0) * Faster implementation of packDecimal. Inspired by [1] I applied the same optimizations to the ByteString implementation of packDecimal. According to the benchmarks I have on hand the new version is about 1.3x faster than the old version. So the difference isn't nearly as impressive; but it's not trivial either. * Added buffer overflow check for asHexadecimal. This only matters if you try converting a ByteString longer than (maxBound `quot` 2 ::Int). I forget if the old version segfaulted or what; but now you get an error message about trying to allocate a buffer that's too large. [1] http://www.serpentine.com/blog/2013/03/20/whats-good-for-c-is-good-for-haskell/ -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestring-lexing -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
