Re: [Haskell-cafe] Errors in non-monadic code
jabolo...@google.com, MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 In-Reply-To: CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com References: CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com quoth Brandon Allbery, Even in IO, exceptions should be reserved for truly exceptional conditions (of the program cannot safely continue variety), not merely for error checking when this can be described as a normal flow of evaluation. Exceptions are not simply alternative flow of control, even in procedural languages; they are *disruptions* of flow of control. I think that would be debatable, especially as applied to procedural languages in general. It's very common to use exceptions in routine flow of control in Python programs, if I remember right. Meanwhile, the Haskell library in my opinion somewhat weakens your case by making ordinary conditions into exceptions, for example end-of-file. In the end it's a large grey area. Ideally, what the program has to do, or whether it can even continue at all, is determined by the program using information reported by the function that encounters the error. If there's a good reason why exceptions should be used only when the program won't be able to continue, it must be that the language's exception handling facililty isn't very robust. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
quoth Richard A. O'Keefe, ... If you're familiar with *English* rather than, say, the C family of programming languages, return isn't _that_ bad, there is certainly nothing about the word that suggests providing a value. The RFC822 headers of your email suggest that you use a Macintosh computer, so apart from the apparently disputable question of whether you're familiar with English, you have the same online dictionary as mine. Second definition: give, put, or send (something) back to a place or person, with examples she returned his kiss, usage from tennis and football, verdicts, etc. Third definition: yield or make a profit, fourth (re)elect a person or party. Return is all about providing a value, in English. When a term like return is used in a computer programming language in a sense that confounds any prior expectation based on English or other programming languages, that's the opposite of intuitive. It is what it is, and it's silly to talk about changing it at this point, but that doesn't mean that we have to turn the notion of intuitive on its head. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
quoth Richard A. O'Keefe Check the OED. Most of its meaning are about _turning back_, _resuming_, _reverting_. Yielding or making a profit is not at all about providing a value, but about money going out AND COMING BACK. It's the coming back part that makes it a return. Yes. Return means 'go/come back'; used transitively, it means 'go/come back with _'. value occurs twice in OED 'return, v.1, in neither case referring to providing a value. But of course, the word value as we use it is specific to our application, i.e. it's computer jargon, with an English meaning that's more like thing, object, datum. Wouldn't look for value to convey this meaning in an OED definition of return. In all of the senses, the underlying idea is not provision of a value, but going, turning, or bending back. [Which is actually what the Haskell return fails to do.] What goes/turns/bends back? When used intransitively, the subject; used transitively, the object, our value. I'll give you the COBOL example, it's no better the Haskell return. FORTRAN makes a good deal more sense for an English speaker but uses indirect object semantically - RETURN 2 means return to the second alternate return specified by the caller. (I never used that feature, so don't take my word for it, check your manual before using it!) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
quoth David Thomas davidleotho...@gmail.com, It strikes me as unlikely static analysis would be confused by shadowing. Not to mention that the example only created two expressions of type IO Fd? (I.e., no file descriptors were opened, let alone leaked.) But in any case, I would have guessed that the idea here is that much more than a few examples and counter-examples will be needed to validate something like `shadowing is bad.' If the assertion isn't too simplistic, the examples sure will be. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]
quoth Alberto G. Corona, Let is recursive because, unlike in the case of other languages, variables are not locations for storing values, but the expressions on the right side of the equality themselves. And obviously it is not possible for a variable-expression to be two expressions at the same time. The recursiveness is buildt-in. It comes from its pure nature. I'm surprised that it would come down to purity. It looks to me like simply a question of scope. I had to write an example program to see what actually happens, because with me it isn't intuitive at all that the name bound to an expression would be visible from within the expression itself. I suppose this is considered by some to be a feature, obviously to others it's a bug. I've gone to some trouble to dig up an nhc98 install (but can't seem to find one among my computers and GHC 7 won't build the source thanks to library re-orgs etc.) Because, I vaguely recall that nhc98's rules were different here? Anyone in a position to prove me wrong? thanks, Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]
quoth Andreas Abel andreas.a...@ifi.lmu.de, ... I would doubt that nhc98 would interpret let xs = 0 : xs differently than ghc if it implemented anything close to the Haskell 98 standard. What I (so vaguely) remember was a compile error, for some reuse of an identifier where GHC permitted it. I suppose you're right, anyway, probably something else - maybe unambiguous nested shadowing? let x = t + 1 in let y = x in let x = y + 1 in x GHC allows this, and of course there's no recursion. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess interferes with sockets?
quoth Evan Laforge qdun...@gmail.com,
...
and it still waits for the subprocess to complete. Actually, it looks
like it's the client's hGetContents, since hGetChar comes back
immediately. I guess that's understandable, but even hGetLine blocks.
In the version I was looking at, if I change the server's output
{-- IO.hPutStr hdl response --} to response\n, it works. Otherwise
hGetLine will still be polling for the newline that will never come.
System.IO doesn't seem to have a hRead :: Int - IO String, I guess
you have to go down to the POSIX fd level, or read char-by-char.
In the present case I believe we'd be talking about
Network.Socket.ByteString.recv. With a POSIX device like a pipe,
then System.Posix.IO.fdRead.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess interferes with sockets?
quoth Evan Laforge qdun...@gmail.com, ... Oh I see, because the subprocess inherits the socket connection. That makes sense, though it's tricky. Tricky tricky unix. Why does fork() have to be so complicated? Well, it's very elegant really. It's one of the tools UNIX gives you to decompose a task into discrete modules, programs running in separate processes - but inheriting file descriptors and other common environmental stuff. And in some respects should feel familiar to a Haskell programmer - can't modify parent's environment, etc. For me, moral in the story should be that buffered I/O is not robust, for a socket device or anything like it (UNIX pipe, whatever.) That isn't about UNIX, it's just inevitable. Maybe your client is really going to need the timely EOF anyway, but the immediate problem was that the server wrote to the socket and the client couldn't see it. Because the client read is buffered. Not robust. Some programmers are so wedded to the buffered language platform I/O functions that they'll find a way to defeat the buffering or work around it. That can be nonperformant where the semantics of the read depend on buffering, like getLine; don't know what would happen with hGetContents. The path that makes sense to me is low level I/O (read/recv) that simply returns what's there, up to the specified limit. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess interferes with sockets?
Quoth Evan Laforge qdun...@gmail.com,
sleep = Process.createProcess (Process.proc sleep [5])
sleep = Process.createProcess
((Process.proc sleep [5]) {Process.close_fds = True})
- Because the client uses buffered I/O (hGetContents in this case, but
hGet-anything would be the same), it doesn't see the server response
until a) buffer full, or b) end of file (server closes connection.)
- The server does close the connection, but after the sleep process
has forked off with a copy of the connection fd. If it doesn't close
that fd explicitly, it holds it open until process exit (5 seconds.)
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overloading
On Mar 13, 2013, at 12:54 AM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: The interesting challenge here is that we should have Date + Period - Date Date - Period - Date Period + Date - Date Period - Date - ILLEGAL Period + Period - DeriodPeriod - Period - Period Date + Date - ILLEGAL Date - Date - Date and _also_ (remember we are trying to beat C++ here) Int +/- Int - Int. I think I would also want Period * Int - Period Period * Period - ILLEGAL Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overloading
Peter Caspers pcaspers1...@gmail.com, data Month = January | ... ok, I will try to change my code in that direction. The idea is clear. To whatever extent these algebraic data types do map to integer values for your purposes, you can implement that by making Month an instance of Enum. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about forkIO
Quoth C K Kashyap ckkash...@gmail.com, ... Say I have a haskell function 'f' that does a forkIO and starts an action a. I create a DLL of this haskell code and inovke f from C. Can I expect the a to continue to run once f has returned to C? Once control returns to f's caller, outside of the Haskell runtime, then there isn't any way to dispatch IO threads - that's done by the runtime, so it can happen only while executing in the runtime. I am not a forkIO expert, that's just how it appears to me from my limited understanding of how they work. For extra credit - do the old IO threads resume if you call 'f' again, so you'd have more each time? (I don't know!) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to return a network connection to C
Quoth C K Kashyap ckkash...@gmail.com, I am using http://hackage.haskell.org/package/connection. So I create network connection in Haskell getConnection :: IO Connection I'd like this connection to be returned to C so that subsequent calls from C can send in the connection handle. According to the documentation, he doesn't export enough of the Connection type to access the handle inside, and there appears to be no function provided to do that either. So it looks to me like you'd have to 1) make the connection by hand with Network.Socket.connect etc., 2) get the Socket fd, 3) make a Handle from the Socket, 4) pass that to connectFromHandle, and 5) use the fd with your C function. Note that the socket connection itself, represented by the fd that you return to C, will simply transmit data back and forth without modification. Specifically without SSL encryption. If you need SSL encryption in both Haskell and C, it would probably be simpler to implement the I/O in C and call it from Haskell. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to return a network connection to C
Quoth C K Kashyap ckkash...@gmail.com, Hey Donn ... when you say, implement the IO in C, you also imply implementing the SSL stuff too right? Yes, if you need encrypted I/O from C. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Haskell way to implement flags?
Quoth Branimir Maksimovic bm...@hotmail.com, In C usual way is to set some bit in integer variable by shifting or oring, and than check flag integer variable by anding with particular flag value. What is Haskell way? Of course you may do the very same thing, if you like. I think if there's only one of these for the entire program, most Haskell programmers would use a Boolean value, as the space you save with a single bit is of too little consequence to bother with bit twiddling in Haskell. The various flags that belong together might be housed in a `record'. Or, in some contexts a list of an algebraic type might be useful - like, if elem FlagDebug flags, or if any (flip elem flags) [FlagDebug, FlagVerbose] Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
Quoth Ryan Newton rrnew...@gmail.com, The scenario is pretty simple. I generate C code at runtime. I compile it to a .so. I know how many arguments it expects (but only at runtime), and I get a FunPtr back from 'dlsym'. How do I call it? I was hoping there would be some Raw lower level FFI layer that I could use to invoke a C function without automagic marshaling and all the other goodness provided by the normal foreign import mechanism. I feel that I might be confused about the problem, but since I don't see anyone direct answers -- in order to call a FunPtr, you can use foreign import ccall dynamic, to create a regular function. As described in the library documentation for Foreign.Ptr, which I bet you've seen, so you know this. You can cast the FunPtr to whatever type you like, so you can call the function with an argument list different from its initial declaration. There are two types of support you don't get, as I see it: 1) Haskell isn't going to make it really super convenient to use a variably typed function, and 2) there's the argument promotion issue mentioned in the document you cited. On that second point, however you go about this, you'll need to thoroughly understand what that means, but it won't strictly prevent you from calling this function, just puts you on notice that the FFI is blind to the argument types and will make default assumptions, so your C function needs to support that. On the first point, of course that's how Haskell is - and from a design point of view, if you're writing C code to be called from Haskell, wouldn't there be better ways to accommodate variable inputs than the argument list? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
Quoth Ryan Newton rrnew...@gmail.com, ... Anyway, in this case it wasn't *too *painful to just generate a bunch of extra boilerplate C functions for (1) creating a data structure to hold the arguments, (2) loading them in one at a time, and (3) deallocating the structure when the call is done. Yuck. But no extra dependencies. If I understand you right, that's a better direction in my view - and when I've done stuff like this I've allocated and marshalled the data structure from the Haskell side fairly painlessly with Foreign.Storable(poke) etc., and the .hsc preprocessor macros for struct access (#poke, etc.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ifdef based on which OS you're on
As counterpoint to Vincent Hanquez' note about the certificate store on MacOS Windows, I'd like to cast some doubt on the notion that you can reliably find the cert store here on Linux or the *BSDs. So, if my experience with platforms like that is any guide, you'd rather not hard code this value in any case. I suppose that means application needs a configuration file. #else SSL.contextSetCADirectory ctx /etc/ssl/certs SSL.contextSetVerificationMode ctx $ SSL.VerifyPeer True True Nothing #endif On the bright side, a configuration file makes operational parameters like this very transparent for a sys admin who needs to work with it but wasn't in on the original install. Assuming the config file is easy to find in the first place. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
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 libraries? Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I've done it, for my own amusement - wrapped a C++ graphics toolkit and used it to write a couple small applications. Most of us would probably object to your transformation/interaction evaluation as presented above ... but it depends on your motivations. In my case, I simply wanted to use Haskell, and in fact I started with a model like yours where the UI was simply written in C++. There were some very cumbersome things about that arrangement though, so I was happy to integrate Haskell into the UI as soon as it became possible. On the other hand ... I'd be lying if I said the Haskell code is cleaner, or really advantageous in any compelling way if we're just talking about the UI. It has its moments - Haskell is always going to pull a few things off pretty well, in a UI or whatever - but of course, this particular UI API is specifically more suited to C++, than Haskell. So given that one can write good, clean code in C++, too, the question is whether Haskell is so vastly advantageous for such applications that it compensates for the sketchy binding. It isn't, I think. Whereupon we come to your original question. Personally, I would just work with the model that's natural to your API. If it's a C++ OO 3D graphics library, then go OO, for the very same reasons discussed above. FP may in principle have all the virtues mentioned in that article, and it's good to be on the lookout for ways you can deploy some of that in a C++ program, but when it comes time to use that OO API, it's what you've got. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I avoid buffered reads?
Quoth Brandon Allbery allber...@gmail.com, On Thu, Dec 6, 2012 at 3:24 PM, Tristan Seligmann mithra...@mithrandi.netwrote: On 29 Nov 2012 12:27 PM, Leon Smith leon.p.sm...@gmail.com wrote: System.Posix.IO and Foreign.This appears to work, but for better or worse, it is using blocking calls to the read system call and is not integrated with GHC's IO manager. This shouldn't be an issue for my purposes, but I suppose it's worth pointing out. Reading from an fd corresponding to an actual file is always blocking. select() will always indicate that the fd is ready for reading and writing, and I think epoll() will refuse to operate on the fd at all. This; it's a longstanding gripe among those of us who use network filesystems heavily, since it's entirely possible those reads *will* block... but the usual architecture of Unix-like kernel filesystem code doesn't provide any way to see it or do anything about it. A wretched state of affairs indeed, but is that the same problem? While I guess /dev/urandom isn't supposed to block, so it would look about the same to select(2) either way, /dev/random is select-able, true? If GHC IO is using blocking I/O on everything opened by name, on the assumption it's talking to a filesystem, then that looks to me like GHC's error, not UNIX's. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Blocking IO FIFOs
From Jason Dusek jason.du...@gmail.com, ... If I could somehow arrange to detect EOF when /tmp/exitpipe is closed, then I might as well redirect 1 and 2 to FIFOs and wait for them to EOF, collecting the output. However, all of my experiments suggest that there is simply no way in Haskell to detect the closing of the write end of a FIFO. With `openFileBlocking', one can detect when a FIFO is *opened*; but not when it is closed. It looks to me like our colleague in another followup may have it working in an example. I have run into some trouble myself, with an example program demonstrating the approach I proposed. With a pre-existing named pipe, that I would just keep using, for whatever reason it worked the first time, failed the second, and so forth, working every other time. If the test program created the named pipe, it failed every time. There are probably reasons for all this, but I haven't looked very hard. That was using withFile. If I use POSIX I/O, it works fine. So it looks to me like there is indeed a way in Haskell to detect a closed FIFO, it just may not be Haskell I/O without a lot more work ironing out the possible causes of failure. I believe that doesn't need to be a problem for you, though, because 1) your application is by nature exclusive to POSIX platforms, and 2) you need the named pipe only to detect command process exit, and you can still apply Haskell I/O to the more interesting data that accumulates in the command output disk file. And there may be an answer for my problems with Haskell I/O. Could be as simple as using openFileBlocking, which apparently isn't supported in the ghc I'm using. Could have something to do with the fine points of named pipes - for example, I believe you're supposed to open them O_RDWR in situations you'd think would call for O_READONLY. (Though the latter worked for me with POSIX I/O.) While I'm here ... I share the concern expressed in an earlier followup about the outputs from bash in runInteractiveProcess. This looks like a feature of runInteractiveProcess that makes it intrinsically something like a code smell. input-only and output-only processes are commonly used and fairly tractable, where input-output processes are unusual and and fragile, so it's an unfortunate convenience. I think the idea is that you'd use createProcess specifying only the input redirection. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Blocking IO FIFOs
Quoth Jason Dusek jason.du...@gmail.com, ... For my application, it's important to be able to run multiple queries against the same Bash session. Waiting for Bash to shut down is thus not a viable way to finalize the response. You could redirect to disk files and also use a pipe to wait for exit. I suppose you redirect I/O for individual queries by applying shell redirections to the command? So like this, uname -a /tmp/cmd1 2 /tmp/cmd2 7 /tmp/exitpipe ... then read from /tmp/exitpipe, ignore empty result and read command outputs from the disk files. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Getting PID of a child process
Quoth Jason Dusek jason.du...@gmail.com, Using `System.Process.runInteractiveProcess', I can start a process and get a handle to it: runInteractiveProcess :: FilePath - [String] - Maybe FilePath - Maybe [(String, String)] - IO (Handle, Handle, Handle, ProcessHandle) For diagnostic purposes, I'd like to print the PID of the process attached to this handle -- how best to do that? There's a good chance this isn't the best way, but it seems to work: import System.Process import System.Process.Internals (ProcessHandle__(..), PHANDLE, withProcessHandle) -- for use with withProcessHandle getPID :: ProcessHandle__ - IO (ProcessHandle__, Maybe PHANDLE) getPID h@(OpenHandle t) = return (h, Just t) getPID h@(ClosedHandle t) = return (h, Nothing) main = do (h0, h1, h2, hp) - runInteractiveProcess /bin/date [] Nothing Nothing mp - withProcessHandle hp $ getPID print mp Seems like more scaffolding than this application really ought to require. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
Since we're talking about forkIO here - not forkOS - is it possible to control the use of OS threads to avoid this problem? As I understand it, the problem is with real OS threads. A program running entirely in multiple `green' threads will fork to the same set of threads in the same state, creating no problem with internal state. I'm guessing this is why he sees the problem at 9 threads - maybe the runtime picks up another OS thread at that point. Of course one could link the unthreaded RTS, and that will cause everything, including runtime gc etc., to run in the parent thread, true? And there are some runtime options to control number of threads scheduled. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Issue building ghc on NetBSD/amd64
Quoth lhagan lhaga...@gmail.com, Just tried changing the flag in build.mk, but I get the same error. Also, I'm pretty sure I need the --enable-hc-boot flag. Without it, I get: configure: error: GHC is required unless bootstrapping from .hc files. Unless I've missed a whole lot of progress on this matter, it's going to be much more work than just getting the flags right. Several years ago, I managed to build 6.8, by starting with an OpenBSD port of 6.6 as an hc donor, and of course building 6.6 on NetBSD, and then using 6.6 to build 6.8. There's a great deal of debugging and patching that needs to be done in the process, some of it already done for i386 and some novel to amd64. I presented it to the NetBSD Haskell maintainer, but obviously it's a low priority - I think in the intervening years, you're the second person to mention it. If that individual (whose identity I can't recall at the moment) has a working NetBSD/amd64 port at this time, of any version, that would be extremely helpful; unfortunately I don't, I think my amd64 hardware is defunct. (I don't think I got the interpreter working, by the way, and that also usually means no haddock, etc.) Today, you'd be obliged to follow the same course, but probably would have to build one or two intermediate GHC versions as I doubt that 6.6 could build the current version. I understand the current version is not able to be bootstrapped from hc files at all. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Alexander Kjeldaas alexander.kjeld...@gmail.com, See access(2) ... a classic code smell in UNIX programming, for the same reasons. We can solve this problem in an efficient way that works well, and equally well, on any POSIX platform that supports F_CLOEXEC on pipes, and I can't think of anything that doesn't. The appended code is the basic gist of it. This was not invented by the Python world, but as suggested it's one of the things that we'd get from a review of their subprocess module. Donn spawn file cmd env = do (e0, e1) - pipe fcntlSetFlag e1 F_CLOEXEC t - fork (fex e0 e1) close e1 rx - readFd e0 256 if null rx then return t else ioerr (chrToErrType rx) file where fex e0 e1 = do close e0 catch (execve file cmd env) (\ e - writeFd e1 (errToChr e : ioeGetErrorString e)) ioerr (e, s) file = ioError (mkIOError e s Nothing (Just file)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Evan Laforge qdun...@gmail.com, ... ... or at least make sure the haskell version doesn't suffer from problems fixed in the python one. Exactly. This morning I'm reading suggested solutions that would work only some of the time, or on only some platforms, which wouldn't be satisfactory in the long run. Though speaking of platforms, I guess one large headache would be what to do about Microsoft operating systems. Given the unusual nature of these functions (I mean, what operating-system-independent command are you going to invoke, anyway?), maybe it would be OK for the more elaborate support functions to be POSIX / Windows specific. At the level where people are redirecting the output FD and not the error FD, etc. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Brandon Allbery allber...@gmail.com, On Mon, Aug 13, 2012 at 10:23 AM, Donn Cave d...@avvanta.com wrote: Though speaking of platforms, I guess one large headache would be what to do about Microsoft operating systems. Given the unusual Microsoft provides APIs that work as is for this, by my understanding; it's the POSIX fork/exec model that makes life difficult. Or interesting, anyway. I wasn't thinking of the `exception in child' problem here, so much as more generally, how much is a fully cross-platform API worth, in a situation where the eventual application of the API is inherently unlikely to be of a cross platform nature. The Python version goes to some length, but can't fully resolve the inconsistencies. That's OK if someone wants to go to the trouble, but if I'm right about inherent platform dependence, it runs the risk of being more irritating than helpful! Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do vs. pattern matching
On Sat, Aug 4, 2012 at 7:05 AM, Alexander Solla alex.so...@gmail.com wrote: On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote: ... With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) ... The short answer is to write a one liner using (=) and (), unless you need to bind more than one value to a variable. In that case, you should use an applicative interface, if available and otherwise possible, and finally do-notation. But the longer answer would be, it depends! Right? The `do' notation is clear and easy to follow; it's low maintenance - even if you have nothing to bind right now, if that comes up in the future, it will drop right into that `do' block; it's classic Haskell that doesn't need any explaining to (hardly) anyone. Maybe it's your last choice, maybe it's my first. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Martin Odersky on What's wrong with Monads
To be fair, while it's great that Functor et al. are available to help solve problems like that with a Tree data structure, in the present context it mostly shows that a trivial example was used to illustrate the problem. Unless I'm missing how this generic fold functionality solves the more general problem. Quoth Alberto G. Corona, ... There is no such problem in imperative languages, which work ever in an hardwired IO monad. Or to look at it from the other direction, the problem with Haskell is that it allows the programmer to write non-IO functions. To the extent that's a real problem, the solution would obviously be to exercise some restraint with the pure code and write more in the IO monad. If you will humor me, we understand that this code is equally satisfactory from a mathematical perspective and there's no crime in it. But does it help with the `flags problem?' Suppose that functions f and g both have IO types; f calls g, and g has optional behavior depending on some IO value computed previously, the flag. The way I understand it, I can accomplish this without passing the flag around: with an IORef. What's less clear to me is whether Haskell really supports the module level accessible IORef value I need. Also known as top level mutable state. Is the NOINLINE pragma I've been using with GHC, really a sound and reliable practice that we're reasonably confident will be supported by other compilers? It feels to me like I'm pulling a weird trick, to do something that's trivial in other programming languages. Maybe that's part of the problem, that imperative programming receives something a little short of full support in Haskell, inasmuch as basic features like top level mutable state require relatively arcane incantations. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
Quoth Anthony Cowley acow...@seas.upenn.edu, ... I think this is a consequence of line buffering rather than a bug. If you write your own increment function in Haskell, you get the same behavior. If you `hSetBuffering stdout NoBuffering` before your `putStr` call, you should get the behavior you wanted. Though if you must do one or the other, I think hFlush makes as much sense. I think his perspective may be that the C stdio library appears to recognize that a TTY read is an occasion to flush stdout. If you already know better, there are ways to solve this problem - flush, change buffering, or use stderr instead of stdout. If you weren't expecting it, though, Haskell might by comparison seem a little retarded. Maybe it isn't a bug. As things stand, it is quite a hassle to use a Haskell library of any complexity called from C. And Haskell is slightly handicapped in this application, if it still doesn't support any good mechanism for top level mutable state (Cf. http://www.haskell.org/haskellwiki/Top_level_mutable_state ) I wonder if the fact that we recognize these problems but haven't been super-motivated to solve them, suggests that there hasn't really been that much call for stand alone Haskell libraries? (The proposal seems to say that C++ programmers could jump at this opportunity because they've been wanting to use Haskell but were afraid of the IO Monad?) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
On Wed, Apr 4, 2012 at 6:37 AM, tsuraan tsur...@gmail.com wrote: What sorts of things can cause a thread to get an asynchronous thread killed exception? I've been seeing rare, inexplicable thread killed messages in my Snap handlers for a long time, but they aren't from Snap's timeout code. This is a long shot, but it's easy to test - turn off GHC's RTS timer, +RTS -V0 -RTS. That removes a source of SIGALRM interrupts. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Quoth Jeff Shaw shawj...@msu.edu, ... I'm thinking that side effects are really only necessary because Haskell programs expect to mutate the state of a computer outside of the haskell program. I'm not a computer scientist, but in English, side effect is an effect that accompanies some other effect. E.g., you may take an antihistamine to relieve hay fever, and experience a side effect of drowsiness. Let's call the first an `intended effect'? Then in the matter of the computer outside the Haskell program - which is intended effect, and which is side effect? I'd have said, side effects would be like memory paging, deferred resource access for other processes, etc.? Some programs might leave behind temporary files ... I hope the answer is not that in computer science we regard all effects as side effects because the ideal computer program simply exists without consequence. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Quoth Chris Smith cdsm...@gmail.com, ... The answer is that side effects has become something of a figure of speech, and now has a specialized meaning in programming languages. When we're talking about different uses of the word function in programming languages, side effects refer to any effect other than evaluating to some result when applied to some argument. For example, in languages like C, printf takes some arguments, and returns an int. When viewed as just a function, that's all there is to it; functions exist to take arguments and produce return values. I'm surprised by the use of function as a unit. I would have expected expression or something, but maybe that isn't semantically interesting as long as one can't exist independent of the other. ... But C extends the definition of a function to include additional effects, like making Hello world appear on a nearby computer screen. Because those effects are aside from the taking of arguments and returning of values that functions exist to do, they are side effects... even though in the specific case of printf, the effect is the main goal and everyone ignores the return value, still for functions in general, any effects outside of producing a resulting value from its arguments are side effects. If that's so, it's unfortunate. It would have been more profitable to confine the application of this term (side effect) to the context of the program, where it 1) makes sense in English, and 2) applies to a programming device that has always been of some interest. I have a little trouble defending this point of view because there's some overlap, inasmuch as the program may also retrieve values via external I/O. And Haskell provides writeIORef/readIORef as a convenient way to demonstrate that as a technical side effect without resorting to actual I/O. Still, the use of I/O and similar techniques to create a side effect are interesting as such, and my point is that if we call every I/O a side effect, the term loses its value as a way to describe this programming feature. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Quoth KC kc1...@gmail.com, On Fri, Mar 16, 2012 at 7:44 PM, Jerzy Karczmarczuk jerzy.karczmarc...@unicaen.fr wrote: ... but the question of purity of a program - in my opinion - concerns the program, and nothing else. You might be thinking of software engineering purity. Or software engineers might be thinking of purity in the same way. I personally hope I think of purity in a way that's of some practical use in terms of Haskell programs, and I would hope software engineers in general would do likewise. From that perspective, it seems to me that M. Karczmarczuk is on pretty solid ground. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preventing leaked open file descriptors whencatching exceptions
Quoth Bryan O'Sullivan b...@serpentine.com, On Tue, Feb 21, 2012 at 8:16 AM, Ryan Newton rrnew...@gmail.com wrote: FYI, lsof confirms that there are indeed many many open connections to the same FIFO: Like all of the lowest-level I/O functions, openFD just gives you back an integer, and the Fd type has no notion that there's an underlying system resource associated with it. It's your responsibility to manage it (i.e. clean up manually when catching an exception). What's more - if I understood the hypothesis correctly, that the exception occurs during openFd - that fails to return an Fd because the open(2) system call fails to return one, so it would presumably be an OS level bug if there's really an open file descriptor left from this. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr
Quoth =?ISO-8859-1?Q?Yves_Par=E8s?= yves.pa...@gmail.com, You mean I have to use a type like StablePtr (IORef Stuff)? Because there I can only peek (deRefStablePtr) the pointer, not poke it. I take it I should return to C a StablePtr to the new value if I don't want to use IORefs... Yes ... Or else I have to use regular Ptrs with Foreign.Marshall.Alloc.malloc yes! Both of these are good ways, to do different things. In your initial message, you asked about a foreign function modifying a value in storage accessible from Haskell - that's regular Ptr. Either way, read or write, communication with the foreign layer is through Ptr, not StablePtr. StablePtr is for Haskell expressions, which would be totally inscrutable to the foreign function anyway, and which naturally do not expect to be modified, so yes, a new value shall be attached to a new StablePtr. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr
Quoth Yves Pares, ... If StablePtrs cannot have their pointed value modified (either C or Haskell-side), that mostly limits their interest, doesn't it? I'm not sure I follow what's happening in the two cases you mention, but in case it helps, I use StablePtr as a way to smuggle Haskell values through a non-Haskell layer. On the other side, they are just things - not really pointers, so while void* is all right as long as it's the right size, it is a little misleading. Tag might be a better word. castStablePtrToPtr doesn't change that - you still get a tag, not a memory address. I can think of no use for it, unless you want to call a function that happens to use a Ptr () without expecting it to point somewhere in the memory address sense. Since they're Haskell values, it would be perverse to modify them. I just want them back, in a Haskell function dispatched by the other layer. If I want to pass data per se to the other side, I have to marshal it to be readable CInts and such, and then pass it as a Ptr. And/or if the data is to be modified by the other side, same deal, I have to un-marshal it back into Haskell. I actually use them with a C++ layer, where of course the dispatch happens through C++ object member functions. That allows me to map Haskell functions to the C++ API in a C++ derived class that just maintains a table of the actual Haskell `member functions', and a StablePtr for the actual Haskell data. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth Evan Laforge qdun...@gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating the obvious, is it fair to say the root
of this problem is at least the lack of `first class' update syntax?
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config = modifyConfig tempo (+ 20) config
... but today you get `fr' is not a (visible) constructor field name
So you need a modifyConfigTempo, etc. - when even the above is
inconveniently specific, as we'd rather have
modifyRecord :: RecordType r = (r - a) - (a - a) - r - r
I'm not saying modifyRecord (+ 20) tempo config would be the ideal
syntax for everyone who's been dreaming of records improvement, just
trying to get at the underlying problem with minimal syntactic
distractions. Nested structure doesn't look like a special problem -
modifyRecord innerRecord (modifyRecord inInField (+ 20)) outRecord
An operator with some infixing doesn't seem to buy a lot -
(innerRecord \{} (inInField \{} (+ 20))) outRecord
... but better might be possible without sacrificing composability.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update
Quoth AntC anthony_clay...@clear.net.nz,
...
No, Donn, it's not the lack of syntax, it's the lack of semantics for first-
class (polymorphic) record update. And there's very little that's obvious.
Ah, you're right, I certainly shouldn't have used the word syntax there.
But just to be clear on the point, I wonder if you could expand on what
you mean by polymorphic above.
I mean, when I wrote
modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
... while this does obviously represent a polymorphic function,
if I write
data Config { tempo :: Int, ...}
f = modifyRecord tempo (+20)
... then f has type Config - Config, it isn't polymorphic.
I am however vaguely aware that some parties to the Record
Question would like to make record fields themselves polymorphic, so
that 'tempo' could be defined for multiple record types and 'f'
would, I suppose, have a type like RecordThatHasTempo r = r - r
Maybe that's semantically more like overloading, but in any case,
it isn't strictly necessary in order to support first class updates,
true?
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth Evan Laforge qdun...@gmail.com,
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote:
...
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config = modifyConfig tempo (+ 20) config
I think lenses already do better than this, since not only are they
more concise than the above (once you've resigned yourself to a few TH
splices), they aren't restricted to being only record fields.
How more concise? Because =# is more concise than `modifyRecord', etc.,
or is there some real economy of expression I missed out on? Asking
because, honestly I didn't get your earlier example -
setTempo :: Config - Config
setTempo y = Config.deflt#Config.tempo =# y
... something's missing, I thought - but maybe it's conciser than
I can reckon with!
The rest - the functions that look like fields, the enforcing invariants,
etc. - are cool as lens features, but for Haskell records in general it
seems like something that would call for a lot of discussion. Compared
to first class record update, where it's easy to see how close to broken
the current situation is.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update
Quoth AntC anthony_clay...@clear.net.nz, Donn Cave donn at avvanta.com writes: ... The narrow issue we're trying to address is namespacing, and specifically name clashes: two different records with the same named field. ... Now in return for me answering that, please answer the questions in my earlier post about what limitations on update you'd like: * record-type changing? * Higher-ranked fields? * How many forall'd variables? * Constrained forall'd variables? All right, but it won't be a very interesting answer; partly because I personally do not find the name clash issue per se as compelling as some - I mean, it can be a nuisance for sure, but it isn't broken the way update per se is broken - and partly because, as best as I can make out, I have never dreamed of using any of those four features. So I hope someone with more invested in the problem will chime in! Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz, ... It was a surprise to me that dot without spaces around is still legal syntax for function composition. It isn't even unusual. You can find stuff like fromIntegral.ord in packages downloaded to build cabal-install for example. It graphically appeals to the notion of a function composed of several functions, so the programmers in question will likely not even be repentant! It's hard to imagine this all going anywhere, really, without some way around the code breakage. Maybe a different separator, like record\field, that really doesn't occur in infix like that. Are all pseudo- or virtual or calculated 'fields'. (Or if not fields, then attributes or properties.) I presume you're not suggesting we have both a function `area' and a pseudo- field `.area'? Well - there's no conflict between those two names, if `.area' is an identifier that starts with a dot. But virtual or calculated fields would presumably not be supported. Depends on whether it's legal to define a function `.area', or `.' spelling is allowed only for declared record fields. Personally I think the latter would be the right choice there - left of the dot must be a record value, right of the dot must be a field declared for that record. I understand this is not the direction you're going. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz,
...
We're on the slippery slope! Where will it end?
And now that I've found it, I so love:
customer.lastName.tail.head.toUpper-- Yay!
... compared to present practice, with where dot is function
composition only -
(toUpper.head.tail.lastName) customer
So two competing meanings of ., where one is literally the reverse
of the other. Of course we won't be able to spell composition
without spaces any more, so technically the backwards and forward
sense of . are distinct, but it seems kind of unfortunate anyway.
...
If you'll consider an idea from the peanut gallery ... for me, the
dot notation for fields may as well be spelling as an operator -
that is, customer.lastName deploys a field named .lastName.
If someone modified Haskell to allow postfix notation from this
perspective, when compiler sees customer.lastName, it would
look for an identifier .lastName, so it would work only where
the fields are so declared:
data Customer = Customer { .lastName :: String, .firstName :: String }
Without explicit dot nomenclature (as per current practice), only
normal function application syntax would be supported (as per current
practice.) Unspaced composition (fromInteger.ord) would still be
broken, I suppose, but the error (Not in scope: `.ord') would at
least be pretty obvious.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz, ... My proposal is that field selection functions be just ordinary functions, and dot notation be just function application(tight-binding). Then: object.fieldfuncmethod == fieldfuncmethod object (Subject to the tight binding for the dot.) And one-sided dot application is pointless (! errk I mean 'without purpose', no different to writing the bare object or bare fieldfuncmethod). That's interesting! The wiki page on SORF (Simple Overloaded Record Fields, http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields) has some language that, as I interpreted it, meant that Has/Get syntactic sugar depended on the dot, so it's indispensable. Your proposal actually has some similar language but, I see you don't mean it that way. That's great news for anyone who's really dying to get somewhere with records, if it means that the functionality could in principle be introduced independently of changes to the interpretation of . that would break a lot of code. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 30/01/2012 07:09, Donn Cave wrote: ((separate . crack . .smallEnd) egg).yolk (f egg).yolk where f = separate . crack . .smallEnd Scary - that .smallEnd worries me. It's like a field is being referenced with some magical context from nowhere. Obviously I need to read that full proposal. As I said: (assuming for the sake of discussion a functional dot notation .field = \ r - r.field) By that, I meant to say that I just made that up. I am sure that various proposals have made some notational provision for `\ r - r.field', but it may or may not be `.field', I don't recall. But that's all the magic there is to it. Either you have a notational shorthand for it, or you're obliged to write out `\ r - r.field' Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exceeding OS limits for simultaneous socketconnections
Quoth Marc Weber marco-owe...@gmx.de, ... - replace getContents conn by something strict and close the handle yourself? (not sure about this.) That's an easy one to try, right? Just force evaluation of the getContents return value, in getMsg. If lazy I/O is the culprit here, it wouldn't be the first time. But that will only reduce the magnitude of the problem (albeit perhaps vastly reduce), and as you say, the more reliable solution is to limit the number of concurrent accepts, and concurrent open-and-sends. It isn't like socket I/O really benefits from unlimited concurrency, as all the data is still serially pushed through a wire; you just need enough concurrent peer connections to keep the interface busy. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell Cafe] strict version of Haskell - doesit exist?
Quoth Richard O'Keefe o...@cs.otago.ac.nz, ... On the other hand, a designed-to-be-strict language-and-libraries with close-to-Haskell *syntax* would be nice. I recently described F# as combining the beauty of Caml with the functional purity of C# -- both of course are like the snakes of Ireland. Ouch, the beauty of Caml, tsk. I guess it may not have been a very lively project of late, but the Timber language, a descendant of O'Haskell, is supposed to be strict, I suppose because they were using it in real time controllers. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 28/01/2012 13:00, Paul R wrote: ... All this dot syntax magic frankly frightens me. Haskell, as a pure functionnal language, requires (and allows !) a programming style that just does not mix well with object oriented practices. Stretching the syntax to have the dot feel a-bit-but-not-really like object oriented programming, mainly to have IDE autocompletion on some cases, does not make much sens. In the glasgow-haskell-users discussion, it has been pointed out (to little apparent effect) that the current notation for access by field name, `field record', is naturally functional and is easier to read for a functionally trained eye than a postfix `record.field' alternative. It isn't so much of an issue for OO programmers because the languages are also procedural and the expressions tend to be simpler. In a language like Haskell, an expression could switch back and forth several times between pre-fix (functional) and post-fix (dot) notation. Like, `yolk (separate (crack (largeEnd egg)))' becomes `(separate (crack (egg.smallEnd))).yolk' That elementary example doesn't give me much trouble, but it sure doesn't seem to be much of an improvement in notational elegance. See how natural the transformation with function composition - yolk (separate (crack (largeEnd egg))) yolk ((separate . crack . largeEnd) egg) yolk (f egg) where f = separate . crack . largeEnd ... compared to the re-shuffing necessary with post-fix dot notation (assuming for the sake of discussion a functional dot notation .field = \ r - r.field) (separate (crack (egg.smallEnd))).yolk ((separate . crack . .smallEnd) egg).yolk (f egg).yolk where f = separate . crack . .smallEnd Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, By openFile you, probably, mean openFd. Yes, sorry! Another point is the number of open files, for a long loop. ... toA_IO = openFd toA WriteOnly Nothing defaultFileFlags ... When applying axiomIO in a loop of 9000 strings, it breaks: too many open files. I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). toA_IO is a global constant of type IO Fd, not Fd. You now see the importance of this distinction - the action actually transpires at toA - toA_IO, and each time that executes, you get a new file descriptor. Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO ... (I need to understand further whether my usage of unsafePerformIO really damages the project). It's actually similar to the way some libraries initialize global values, but there are some additional complexities and it isn't clear to me that it's all guaranteed to work anyway. You can read much more about this here: http://www.haskell.org/haskellwiki/Top_level_mutable_state I'm no expert in this, but they're sure here on haskell-cafe, so if you want to take this up, you might start a new topic here, something like global initialization with unsafePerformIO, describe what you're doing and explain why you can't just pass the open file descriptors as function parameters. ... Indeed. Initially, I tried C - C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). I don't know. When I was younger, I used to track these problems down and try to explain in detail why buffered I/O is a bad bet with pipes, sockets etc. I don't think anyone listened. I think I am going to experiment with I am old, so listen to me and see if it works any better. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, [ ... why in Haskell instead of FFI ... ] Because it is a direct and the simplest approach. Why does one need a foreign language, if all the needed functions are in the standard Haskell library? The GHC Haskell library makes some compromises with normal I/O functionality for the sake of its runtime thread system. As difficult as named pipes can be in any case, they can be even trickier in GHC Haskell for this reason. I didn't suggest an FFI approach myself, in my previous follow-up, only because if you haven't worked with the FFI it's a significant initial investment, but I believe it's what I would do. (If I were somehow compelled to used named pipes.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, ... Initially, I did the example by the Foreign Function Interface for C. But then, I thought But this is unnatural! Use plainly the standard Haskell IO, it has everything. So, your advice is return to FFI ? Well, it turns out that the I/O system functions in System.Posix.IO may work for your purposes. I was able to get your example to work with these functions, which correspond to open(2), read(2), write(2). I would also use these functions in C, as you did in your C program. Haskell I/O functions like hGetLine are analogous to C library I/O like fgets(3) - in particular, they're buffered, and I would guess that's why they don't work for you here. Specifically, openFile toA WriteOnly Nothing defaultFileFlags openFile fromA ReadOnly Nothing defaultFileFlags fdWrite toA str (str, len) - fdRead fromA 64 return str Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to terminate the process group of aprocesscreated with createProcess?
Quoth Brandon Allbery allber...@gmail.com, On Thu, Jan 12, 2012 at 06:56, André Scholz andre.sch...@uni-bremen.dewrote: gid - createProcessGroup pid but i get the error message: createProcessGroup: permission denied the documentation for terminateProcess is incorrect and should not mention process groups Right - and terminateProcess should _not_ be fixed to work like the documentation says! I think it's just a point of confusion over how the shell works - in fact, process groups are normally created by the shell, but only when it's serving as the top level interactive shell. In any case, I would not mix System.Process and System.Posix.Process. I'd probably use the latter, but that's because it's closer to what I'm used to as a Unix/SVID/POSIX programmer. Same here, and in any case I don't expect there's any way to do this with System.Process, i.e., portably on non-UNIX platforms. In the System.Posix.Process variant, you get to use fork directly: spawn :: String - [String] - IO ProcessID spawn exe cmd = forkProcess $ executeFile exe False cmd Nothing To set the process group, spawnpg exe cmd = forkProcess $ do getProcessID = joinProcessGroup -- equivalent to setpgrp() executeFile exe False cmd Nothing ... to terminate the process group, signalProcessGroup sigTERM pid ... and wait for the spawned process getProcessStatus True False pid When you're running Haskell in the child fork like this, you could run afoul of runtime thread support, and depending on your situation it might make sense to move the fork/setpgrp/exec out into a C function to avoid that. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, (I wonder: is this for beginn...@haskell.org ?) No, not really! As already mentioned, the use of UnsafePerformIO goes a little beyond what I think is its intended purpose, and I think you might have better luck here with a test program that illustrates the problem and doesn't depend on that. But while you're looking into that ... you might be interested to know that there's a problem with named pipes in GHC (beyond the problems that afflict anyone who tries to work with named pipes.) GHC I/O routinely sets file descriptors to non-blocking, unlike the IO libraries for C and other languages, and this could add to your troubles with named pipes. You can read up on that and possibly find clues to the present problem. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to terminate the process group of a processcreated with createProcess?
Quoth Brandon Allbery allber...@gmail.com, ... terminateProcess passes on the semantics of kill(2); on SVID-compliant (and I think POSIX.1-compliant) systems, the negative of the process group leader's process ID is used to signal the process group. Note that you may need to arrange for your initial child process to invoke setpgrp() to insure that the parent program is not part of the process group. ... and that stuff can be found in System.Posix.Process. Support for POSIX killpg can be found in System.Posix.Signals, by the way in case you think that would make your intention more transparent. However I'm unclear as to the situation you are encountering, as your example does not appear to be spawning an intermediate process. I missed that at first myself -- he actually invokes time sleep 60. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 30/12/2011 10:41, Bardur Arantsson wrote: This doesn't sound right to me. To me, a side effect is something which happens as a (intended or unintended) consequence of something else. An effect which you want to happen (e.g. by calling a procedure, or letting the GHC runtime interpreting an IO Int) is just an effect. Trouble is, whether it sounds right doesn't really matter - that's just an artifact of the meaning you're most familiar with. Any specialist field has it's own jargon, including old words given new related-but-different meanings. It may help to recall that the point of Haskell is to write computer programs, and by extension the point of discussing its properties and semantics. Mostly we intend to refine our understanding of those properties and semantics; sometimes we may hope to actually improve them by questioning things that haven't been, but perhaps could be, rigorously defined. (That's how I read some of Conal Elliott's recent posts, for example - but of course, it's still a legitimate question: does it matter, if we only want to write programs?) That's why we use terms in a sense that apply meaningfully to computer programming languages in general and Haskell in particular. To do otherwise - for example to insist on a definition of pure that could not even in principle apply to any useful programming language, or a definition of side effect that would have to apply every time a program does anything - seems to me like an inane waste of time, to put it mildly. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 29/12/2011 08:48, Heinrich Apfelmus wrote: ... Well, it's a matter of terminology: impure /= has side effects. The ability of a language to describe side effects is not tied to its (im)purity. Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. ... Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. No, code can be referential transparent and pure and at the same time use IO actions. In order to understand that, you need to untangle the notion you describe above as function result from Haskell function value. We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Again, this is nothing new - it's clear from SPJs Tackling the Awkward Squad that this is what the IO monad is meant for, and if it's evil then at least it's controlled evil. IO is not evil. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Gregg Reynolds d...@mobileink.com, On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: bar 2 = bar (1+1) = bar (5-3) Strictly speaking, that doesn't sound right. Look again at the sentence you trimmed off the end: Of course, the point is that this result is an *IO action* of type IO Int, it's not the Int you would get when executing this action. I believe that more or less points to the key to this discussion. If it didn't make sense to you, or didn't seem relevant to the question of pure functions, then it would be worth while to think more about it. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission deniedwhenfilein use
Quoth Antoine Latter aslat...@gmail.com, ... Would this program then loop: append fromFilePath toFilePath = do str - readFile fromFile writeFile toFile str if 'from' and 'to' where the same file? Currently the locking prevents this. Do you mean, locking makes that work, or just makes it fail in a different way? Anyway, I think that's an example that would have the same issues without hGetContents - that is, any way you set out to overwrite a file by modifying its contents, you have the same problem. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 29/12/2011 18:41, Chris Smith wrote: ... On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote: We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Not to nitpick, but I'm unsure what you might mean by function value there. An (IO Int) is not a function value: there is no function involved at all. I think the word function is causing some confusion, so I'll avoid calling things functions when they aren't. Except that it *is* a function value. He's right, I should have omitted function, I just meant value. I think the rest of what came out when he entered tutorial mode should be very helpful, if there's anything left that remains to be clarified about how Haskell manages to be a pure functional language. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfilein use
Quoth Antoine Latter aslat...@gmail.com, ... http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Wouldn't this lead to 'getContents' and friends being much less safe than they already are? Or would we have to do something at the GHC runtime level of things to add locking? Interesting question. I tend to steer clear of that function, rather than try to keep track of all the things that can go wrong with it! but I would guess, the effect is the same on any I/O strategy that executes the same way: e.g. if you were to read pieces of the file iteratively you would be similarly exposed to the possibility of concurrent modifications. That risk may be less obvious with getContents if you take the naive view that it returns the contents of the file in the same way that normal I/O operations return data, but then you will eventually be punished for that naivety anyway! Are you aware of some possible special issue with getContents? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfile in use
Quoth Andrew Coppin andrewcop...@btinternet.com, On 29/12/2011 04:29 AM, Antoine Latter wrote: ... This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The rationale that followed may have been a little sketchy, but apparently everyone agrees with with the point. I see the ticket led to a discussion on the libraries list - http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Gregg Reynolds d...@mobileink.com, .. A minor point maybe, but germane to the original post (I hope). It isn't - I mean, I'm not really sure what your point is, but the example really returns the same IO value, not just one of the same type. Consider an example with implementation: wint :: Int - IO Int wint a = let s = show a in do putStr s return (length s) Now the expression wint 994 is a value of type IO Int, and any instance of that expression is the same value - an action is not the same as the action's result. You can use this value in pure Haskell expressions with confidence. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
Quoth Hans Aberg, ... For example, I set one entry so that typing x |- a becomes x ⦠a, the TeX \mapsto, in Unicode ⦠RIGHTWARDS ARROW FROM BAR U+21A6. It might be tedious to make a lot of entries, though, but something to start with. Something to finish me with, too. I wouldn't be able to do much in a programming world that used glyphs like that. My vision isn't perfect, but I think it's within a fairly normal range, and it isn't good enough to decode a lot of hieroglyphics at normal font size at reading speed. The ASCII limit of 100 or so normal characters may be a barrier to expression, but it's a boost to comprehension. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
Sorry about the belated response, but this shouldn't be a problem since it isn't going to be very helpful anyway! I've managed to follow the process described on this page: http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project to link Haskell code to a non-Haskell main program, via Xcode. You've probably already seen this, it's mostly about a few iterations of trial and error linking, to get the list of GHC library dependencies, which is what you need whether you're using Xcode or not. If you really need a single library with your code and all those dependencies, that may be technically feasible, though awfully tedious. The only clear problem I encountered while experimenting with it is that GHC run time options need ghc -rtsopts, so they're unavailable if your program isn't built by ghc. I believe I worked around that with a special rtsmain.o, could probably recover the details if that's of interest. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
Quoth Felipe Almeida Lessa felipe.le...@gmail.com, On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery allber...@gmail.com wrote: They *do* terminate; a zombie is a dead process waiting for its parent to reap it with waitForProcess. There's also some POSIX stuff you can do to have them auto-reaped, but doing that correctly and portably is somewhat painful. But zombie processes do consume a row in the process table, right? If so, then it's bad to have them around. Correct. As noted above, clean up with waitForProcess to release this resource. If it's more convenient, that could be done up front, by forking twice and waiting for the intermediate process. One possibly convenient way to do that might be something like runCommand eprover . Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get a file path to the program invoked?
Quoth wren ng thornton w...@freegeek.org, There was a discussion about this recently over on libraries@, IIRC. The short answer is that, at present, there is no function to give you $0. We'd like to add such a function, but it's not been done yet. Part of the problem is that, as Alexey says, the first element of argv is just whatever is passed to exec, which is not guaranteed to be a complete path, a canonical path, or any other specific thing we'd desire. It's not at all straightforward to determine the actual location of the executable, especially not in a platform-independent manner. argv[0] can't be trusted, scanning through $PATH isn't guaranteed to find it (and even if you find something of the right name, it's not guaranteed to be the correct executable), etc etc. This isn't your problem, though. I mean, if the proposed function is to return the path to the executable file, then indeed you have a big problem with argv[0]. argv[0] can be anything - or nothing (it can be a null string.) But if we've turned to the question of whether to return argv[0], that's much simpler: you don't need to consider why a programmer might want it. It's appalling to think that library developers would withhold access to standard POSIX 1003.1 features while they decide whether they approve of them. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't establish subprocess communication
As mentioned by the first person to follow up, you need to set line buffering in the copier program. It's filling up its buffer while you write small lines to it - unlike the test run at the terminal prompt, where it's connected to a TTY device and therefore behaved differently. In a situation where you can confidently say your software will only ever be run in a POSIX environment, I like to use the Posix functions directly, because a buffered Handle on a pipe is nothing but extra trouble, and similarly the convenient wrapping of the POSIX API seems to cause more trouble than it's worth. Did your first attempt fail because the file name was not a complete path? Do that on purpose and see if runInteractiveProcess gives you a useful error message. Engineer some other kind of problem into your copier program, and see what happens to the error message ... oh, rats, it looks like runInteractiveProcess puts unit 2 on another pipe, when you might have worked better for you to leave it the way it was. (This kind of thing is what we call a user friendly API, which is why we say with friends like that, who needs enemies!) Here's how the start process function could be written - import System.Posix.IO import System.Posix.Process startproc = do ip - createPipe op - createPipe pid - forkProcess $ do forRead ip = onStdUnit 0 forWrite op = onStdUnit 1 executeFile ./copier False [] Nothing to - forWrite ip from - forWrite op return (to, from, pid) where forRead (i, o) = closeFd o return i forWrite (i, o) = closeFd i return o onStdUnit i fd = do dupTo fd i closeFd fd -- and then for I/O to the file descriptors (remember to supply -- explicit newlines, if the other process is line buffered, e.g. boo\n, -- But if the other process also uses Posix.readFd, it isn't buffered -- at all, so you don't need newlines. cat is in the latter category, -- but most command line applications are in the former, like, say, awk.) sendrecv to from s = do forkIO $ fdWrite to s return () (v, _) - fdRead from 1024 putStrLn (recvd: ++ show v) -- try it Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Getting started on Mac OSX
Quoth hstenstrom h.stenst...@gmail.com, I have a book on Haskell, and I've downloaded and installed Haskell Platform for Mac OS X. What do I do now? XCode is a requirement, and I have it, but I don't know how to run it. To begin with, I want to test small examples from the book, using ghc or ghci. I have read file:///Library/Haskell/doc/start.html. - Where is the software I've just installed? - How is ghci started? Or the platform, whatever that is? The location of the software is covered in /Library/Haskell/doc/start.html. The key point is that the executables - like ghci - are in your path via /usr/bin. What they mean by should be available in any shell, is that when you run Terminal, you can just type ghci at the prompt. Terminal may be hiding in Applications/Utilities. Apple clearly underestimates the value of this application for its users, but you won't - you're going to be using Terminal a lot, for GHC. You need XCode only because GHC needs its compiler and libraries, you won't use XCode directly yourself just to run examples from the book. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
Quoth Brian Johnson brianjohnsonhaskellc...@gmail.com, ... On further thought, there is something sensible here: the RTS might crash while trying to exit. I propose, for POSIX environments, the following change to SIGINT handling: * SIGINT is transformed into UserInterrupt during normal program execution * Once the RTS is committed to exiting, it resets the signal handler for SIGINT so that any additional control-c causes an immediate exit The picture I get from the commentary (below) is that we're talking about shutting down, one way or another - either gracefully, or if that isn't making satisfactory progress, abruptly on the second ^C. Because the user entered a keyboard interrupt, and the program hasn't installed a signal handler for it. If you have your own shutdown procedure that you want to have happen at that time, then it would make sense to me to catch this exception for that purpose. If you want to handle keyboard interrupts, throughout the lifetime of the program process, then you should handle the signals. If the SIGINT handler described below is too confusing, then I would solve that problem by simply removing it. Programs written in other languages simply abort on unhandled signals, and I'm a little skeptical that there's any reliable way to improve on that. We're just teaching people to press ctrlC twice if it's a Haskell program. Donn From http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals: When the interrupt signal is received, the default behaviour of the runtime is to attempt to shut down the Haskell program gracefully. It does this by calling interruptStgRts() in rts/Schedule.chttp://hackage.haskell.org/trac/ghc/browser/rts/Schedule.c (see Commentary/Rts/Scheduler#ShuttingDownhttp://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#ShuttingDown). If a second interrupt signal is received, then we terminate the process immediately; this is just in case the normal shutdown procedure failed or hung for some reason, the user is always able to stop the process with two control-C keystrokes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
brianjohnsonhaskellc...@gmail.com wrote: The second time I press control-c, it isn't caught -- the program exits instead. Why? I don't know why. Same behavior on my platform (Haiku.) While I imagine someone intimately acquainted with RTS signal handling might be able to explain it, I think the real problem is that Control.Exception.Catch isn't a real signal handler. For example, your program doesn't catch SIGHUP, or SIGALRM, or probably anything but SIGINT. The SIGINT handler looks like more of a quirk of the RTS, than a feature whose behavior you should depend on in great detail. I can use System.Posix.Signals.installHandler to catch ctrlC (SIGINT) in a repeatable way, on MacOS X, so that's working as it should. If you want it to return control to the user interface, that's going to take some work - for all I know, there may be some way to hook a signal handler up with Control.Exception.catch. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered notentirelygreat?
Quoth Chris Smith cdsm...@gmail.com, ... So that's what this is about: do we think of Float as an approximate real number type, or as an exact type with specific values. If the latter, then of course you exclude the value that's larger than the upper range. If the former, then using comparison operators like '' implies a proof obligation that the result of the computation remains stable (loosely speaking, the function continuous) at that boundary despite small rounding error in either direction. In that case, creating a language feature where, in the *normal* case of listing the last value you expect in the list, 0.3 (as an approximate real number) is excluded from this list just because of technicalities about the representation is an un-useful implementation, to say the least, and makes it far more difficult to satisfy that proof obligation. It doesn't appear to me to be a technicality about the representation - the value we're talking about excluding is not just represented as greater than 0.3, it is greater than 0.3 when applied in computations. For example you can subtract 0.3 and get a nonzero value (5.55e-17.) Isn't the problem here with ranges really that they're computed in a way that doesn't work for FP? I mean, when I specify [0.1,0.2..0.5], I really do mean to include 0.5 among those values, as you surmise - so I imply a computation that actually produces that value, i.e., 0.5::Double. The disappointment with iterative addition is not that its fifth value [should be] omitted because it's technically greater, it's that range generation via iterative addition does not yield the values I specified. In other words, a range is a shorthand expression, where the correct value is the one that would have resulted from evaluating the corresponding list of constant expressions. If we don't know how to generate that list correctly for Double, then I suppose range shouldn't be supported, but I thinking I'm seeing hints that we may indeed know how to do this? (I sure don't! though of course for a specific case it can be easy, e.g., (map (/ 10.0) [1..5]).) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considerednotentirelygreat?
Quoth Chris Smith cdsm...@gmail.com, ... I certainly don't agree that wanting the exact value from a floating point type is a reasonable expectation. The *only* way to recover those results is to do the math with the decimal or rational values instead of floating point numbers. You'll get the rounding error from floating point regardless of how you do the computation, because the interval just isn't really 0.1. The difference between those numbers is larger than 0.1, and when you step by that interval, you won't hit 0.5. You may have misunderstand - you're right, it isn't reasonable to expect `exact values' out of 0.1, 0.2, 0.3, etc., in the sense of the values classically denoted by those terms on paper. But I believe they do have specific values of type Double, and it isn't unreasonable to expect the range to produce those values and not some approximation that may have been convenient to compute. I think it's more than reasonable to expect [0.1,0.2..0.5] == [0.1,0.2,0.3,0.4,0.5] and that would make everyone happy, wouldn't it? If it's expensive to compute, hopefully people won't write code that makes intensive use of Double range generation. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirelygreat?
Quoth Richard O'Keefe o...@cs.otago.ac.nz, [ ... re Why would you write an upper bound of 0.3 on a list if you don't expect that to be included in the result? ] Because upper bounds are *UPPER BOUNDS* and are NOT as a rule included in the result. If you write [0,2..9] you - DO expect 0 in the result - DON'T expect 9 in the result - would be outraged if 10 were in the result. Pardon the questions from the gallery, but ... I can sure see that 0.3 shouldn't be included in the result by overshooting the limit (i.e., 0.30004), and the above expectations about [0,2..9] are obvious enough, but now I have to ask about [0,2..8] - would you not expect 8 in the result? Or is it not an upper bound? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirelygreat?
Quoth Chris Smith cdsm...@gmail.com, ... As for Enum, if someone were to want a type class to represent an enumeration of all the values of a type, then such a thing is reasonable to want. Maybe you can even reasonably wish it were called Enum. But it would be the *wrong* thing to use as a desugaring for list range notation. List ranges are very unlikely to be useful or even meaningful for most such enumerations (what is [ Red, Green .. LightPurple]?); and conversely, as we've seen in this thread, list ranges *are* useful in situations where they are not a suitable way of enumerating all values of a type. It isn't a life or death requirement, but I have dealt with enum values that are ordered and that could usefully be represented in a range. Even your example -- given a set of hues, it's sensible to order them following the spectrum, so [Cyan .. YellowGreen] might represent the hues in the set that are at all in the green range. I'm frankly using Enum as an equivalent to C enum, symbolic integers, where the range is more or less implicit as by default the integer values are [0..]. While I (vaguely) understand that Haskell's Enum is different, the C idiom should at least testify that there's some practical value in the notion of a range of Enum, or something like it. Though not with floating point values, of course. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] efficient chop
Quoth Ivan Lazar Miljenovic ivan.miljeno...@gmail.com, Why the extra case for go? The otherwise guard can be part of the second case... I noticed that myself, so I thought let's see if it's just a matter of style that comes out the same after compilation ... ... and after a few minutes fooling around with that, I'm none the wiser. I could not, within the time allotted, make out what's going on in the -fvia-C .hc files. I guess the way to answer questions like this is to apply the function in question to massive amounts of data and infer the answer from resulting performance? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with readProcess
Quoth Charles-Pierre Astolfi c...@crans.org, readProcess cmd [opt1,opt2] seems to execute the following: $ cmd opt1 opt2 That is usually fine, but I'm using an external program that doesn't understand the quotes, so I need to execute instead: $ cmd opt1 opt2 How should I do that? I think your analysis is wrong. I don't know what to suggest, though if you follow up you probably should mention what platform you're running on. Maybe you could devise a simple test program that illustrates the problem? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with readProcess
Quoth Charles-Pierre Astolfi c...@crans.org, I've found my mistake: I was calling readProcess cmd [-p -t] instead of readProcess cmd [-p,-t] That would do it. Not sure what are the semantics of quotation in this case, though. And I'm pretty sure my analysis is wrong because of that :) The principle isn't complicated. In UNIX, anyway, quotes are for the shell - $ cmd a b is a string interpreted by the shell as a UNIX command (path, [args]). If an argument contains white space or something it needs to be quoted, and the shell supports all kinds of ways to do that. Of course it uses the quotes, the executed command doesn't see them. But when a Haskell process function's command takes a list of args, we infer that there isn't any shell interpretation, so no quotes. If you want a shell command, for example because you want a pipeline or something, then you may invoke the shell yourself, like readProcess /bin/sh [-c, cmd -p -t] Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of play with Haskell-Cocoa (Objective-C)bindings?
Quoth Luke Evans l...@eversosoft.com, I'm planning to start an Objective-C/Cocoa project and would like to write it in Haskell as much as possible. Of course, I can contrive to split the project into app logic (Haskell) and UI (Objective-C) with some sort of minimal interface between them; possibly just plain old C FFI. However, I would like an interface that's as 'automatic' as possible - one that preferably means that I don't have to spend a lot of time maintaining a somewhat heavy-weight special interface layer as I grow my code on both sides of the divide. Preferably the suture line is as far over on the Objective-C side as possible, so that I can write pretty much everything in Haskell. Now, I see a couple of references to some options: - HOC seems very close to what I'm looking for, but the project looks pretty 'dormant'. - I see some mention of an Objective-C FFI, but am uncertain if this is in any current build of GHC. Are there any other options up anyone's sleeves? Anybody working on something interesting I could play with? You've probably seen this already and it didn't qualify as something interesting, but http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project still works as of MacOS 10.6 and GHC 7.0.3. No extra libraries or tools needed - you just wrangle your Haskell .o files and all the attendant Haskell libraries into the Xcode project, give Interface Builder Objective C stubs to work with, and call out to Haskell with C FFI. I have done only one program this way, with a very simple interface, not enough to have any real idea how painful it's going to be. (Actually it didn't work with -threaded, and because GHC doesn't do the linking I couldn't figure out how to exercise the new option to allow +RTS options, but it seems to be fine without -threaded.) Until recently, I was concerned about being able to use GC on the Objective-C side, but with Apple's new ARC memory management model, that's no longer an issue. Most Haskell-ObjC bindings that already exist are surely designed for Retain-Release, which I assume is not disrupted by ARC as this is just RR at runtime. I don't know - I'm using standard (C) FFI out of the box, and both languages must support foreign C libraries that manage their own memory, so I perhaps erroneously have not been worrying about it. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XCode Dependency for HP on Mac - old XCodeversions
Quoth Clive Brettingham-Moore hask...@brettingham-moore.net, To get XCode on my 10.6 machine, I... I had quite a hunt recently to find the most recent XCode for my not-so-recent mac... so I'll share what I found: Were you able to look on your install CD? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack space overflow in HaskellNet
Quoth Manfred Lotz manfred.l...@arcor.de, ... The problem seems to lie in the HaskellNet package. If for example I only fetch a specific message m - fetch con 2092 having a size of some 1.2m then I get the same stack overflow. If at runtime I specify +RTS -K40M -RTS it works but takes over 40 seconds to fetch the message. That's not so good, but I wouldn't be surprised if it's a natural parsing problem, I mean it's just a lot of data to run through a Haskell parser. IMAP does give you the means to mitigate the problem - the big data transfer in a FETCH response is preceded by a byte count - but to really take advantage of that, how far do you go? I don't have much experience with general purpose parsers, do they often support an efficient counted string read? Is it OK to return String, or do we need a more efficient type (e.g., ByteString?) Is it OK to return any kind of string value - given that a message part could be arbitrarily long (and needs to be decoded), do you go to a lot of trouble to support large message parts but not extremely large ones? For me, the answer is for the parser to bail out, reporting the counted input as a count but leaving it to the application to actually effect the data transfer and return to finish the parse. That's only moderately complicated, but it's part of a general philosophy about application driven I/O vs. protocol parsing that seems to be mine alone. I have no idea how much could be done to tighten up HaskellNet.IMAP. Someone who understands it well enough might be able to get a miraculous improvement with a strictness annotation or something. Maybe you could track that down with profiling. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack space overflow in HaskellNet
Quoth Manfred Lotz manfred.l...@arcor.de,
In the end the only thing I need is to get the full message because I
want to feed bogofilter to learn that a message is ham or spam.
For the time being I decided to write my own program to fetch the data
because it is a good exercise for a Haskell beginner as I am.
Sure, for a very limited case where you don't have to support any
options at all, it's as easy as you want it to be. All the responses
are one line only and only one to a line, so you can read line by line
(and then switch to block read after a line that ends with {count}.)
The way I understand it, though, you do not need the full message,
you would be better off with the first part only. The following
parts in a multipart/mixed message will just be reams of byte64
encoded nonsense for bogofilter's purposes, true? If you fetch
BODY[1], you may once in a while get more than you need - both
text and HTML versions of a multipart/alternative sub-part - but
that won't happen often.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack space overflow in HaskellNet
Quoth Manfred Lotz manfred.l...@arcor.de, ... I'm not quite sure I understand what you mean. Stack overflow comes from this: forM_ msgs (\x - fetch con x = print) If I change it to: mapM_ (\x - fetch con x = print) msgs there is the same stack overflow. I didn't understand that myself, but neither do I know what might be wrong. One thing to consider is that email messages can be very large. Looking at messages received in the last 10 days I see I have one that exceeds your reported stack size, and that isn't counting the extra space required for text representation of non printing characters etc. There may be messages that you simply can't print. The HaskellNet IMAP fetch is actually FETCH ... BODY[], i.e., the whole contents of the message. Normal practice for giant data files is to send them as part of a MIME multipart/mixed message, and something like the above can proceed with a reasonable chance of success if it avoids these attachments by fetching BODY[1] (or BODY[1.1], etc. depending on actual structure.) I just fetched the 10Mb message I mentioned above to check the structure, and it happened in the blink of an eye - BODY[1] is smaller than the header. I don't see any support for fetch by part, you might have to hack that up yourself. You may ideally also want to fetch BODYSTRUCTURE, but practically I might go out on a limb and predict that you won't run into messages where the first part is a multipart/mixed with a large attachment - so if the object is just a survivable first part, you could live without BODYSTRUCTURE analysis and optimistically ask for BODY[1]. Moving on to practical use of email via IMAP, you'd also want to be able to fetch and decode the attachments. At this point, it's interesting to return to the question of space requirements. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial inheritance
Quoth Richard O'Keefe o...@cs.otago.ac.nz, [ ... re Werner Kuhn An Image-Schematic Account of Spatial Categories ... ] class BUILDING building where specify the behavior of buildings here, if any class BUILDING house = HOUSE house where specify additional behavior of houses here, if any any instance of HOUSE *will* have in its interface everything that any instance of BUILDING will. But ... for those who might be overly influenced by a superficial similarity to OOP here ... the idea that the above relationship makes House a subclass of Building isn't really a natural way to look at it. It's true that a House instance will also have in its interface everything that any instance of Building will, but only because the programmer is constrained to do that. To consider the whole outline: class Building building where ... specify the behavior of buildings here, if any class Building house = House house where ... specify additional behavior of houses here, if any data Shed = Shed shed instance Building Shed where ... define Building functions for Shed instance House Shed where ... define House functions for Shed The Building = House constraint doesn't add anything, it just checks that each instance of House also is an instance of Building. If you omit this constraint, everything will work the same - even the constraint will still be there, implicitly, albeit not at the same level. To me, it's somewhat misleading to use words like inheritance and subclass for the relationship between Building and House, unless there's some feature of the system I missed. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't files flushed at exit?
Quoth Felipe Almeida Lessa felipe.le...@gmail.com, On Sun, Jul 17, 2011 at 10:41 AM, Paul Johnson p...@cogito.org.uk wrote: If you open a file for writing and then exit with output unflushed, then Haskell does not flush the file for you. Â In ghci the program seems to work, but then when you compile it in ghc it mysteriously fails. I've just been bitten by this, but when I went to the bug tracker I found http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes this behaviour and was resolved as invalid. Â So presumably this behaviour is by design. Given that most environments get this right, why doesn't Haskell? If you are asking why finalizers are not guaranteed to run, I don't really know the answer for sure. But if you are asking why that bug was marked invalid, then that's because it's good practice anyway to know the lifetime of you handles, specially since they are a scarce resource. If you need a handle for the whole lifetime of your program, use withFile on the main function. If you don't need it for the whole lifetime, then you already should be careful about not leaving it opened. If your program is a long-running process, maybe you should also hFlush at some points to minimize damage on hardware failures and system reboots. The use of withFile on the main function is a good practice in Haskell only because of this defect in the GHC library implementation. There's no question, if there were two competing Haskell library implementations, GHC and one that worked like buffered I/O in other languages, which one would better support Haskell programmers. It's too bad that doesn't qualify it as valid bug. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI for a beginner
The docs
http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headers
say that -#include pragmas no longer work, but fail to explain how to
load code without them. Suffice to say I have no recourse but trial
and error.
Ah, now that is a GHC documentation question. Can you tell us what
should the docs should say instead? Then we can fix the docs.
- I believe I would say (agreeing with M Parès) that hsc2hs serves this
purpose - put #include termios.h in the .hsc file and use hsc2hs
features like #const and (#peek x, y). The termios example could
cover a lot more ground by operating on the termios struct and calling
tcsetattr directly from Haskell, using hsc2hs # macros (I append an
example implementation), but you'd also want to explain that hsc2hs
is only needed for these # macros, not for FFI in general.
But hsc2hs as of GHC 7.0.3 generates a {-# INCLUDE pragma, which
of course is cause for complaint from ghc. So there might be more
to be fixed, beyond just the documentation. That line probably has
no actual purpose other than to annoy ghc, and as a workaround it
can simply be removed from the .hs file.
- My impression is that Greencard isn't the best way to get started
with FFI and hasn't been for a decade or so, so it should probably
be purged from docs.
- The root page needs some attention from someone who understands
what safe and unsafe mean. Currently (under Improving efficiency)
it cites the conventional interpretation that a function must be safe
if it calls back into the runtime, but neglects to mention that it
must also be safe if it is not to block execution of other threads,
including bound OS threads - so related to efficiency issues you
might want to make any slow I/O operation safe to avoid this.
There may be other points about unsafe that need to be documented.
Donn
{-# LANGUAGE ForeignFunctionInterface #-}
module TTY (clearICANON) where
import Data.Word (Word32)
import Foreign
import Foreign.C
#include termios.h
type TCFlag = (#type tcflag_t)
type Speed = (#type speed_t)
data Termios = Termios {
termios_c_iflag :: TCFlag
, termios_c_oflag :: TCFlag
, termios_c_cflag :: TCFlag
, termios_c_lflag :: TCFlag
, termios_c_cc :: [CChar]
, termios_c_ispeed :: Speed
, termios_c_ospeed :: Speed
}
deriving Show
instance Storable Termios where
sizeOf _ = #size struct termios
alignment _ = alignment (undefined::CDouble)
peek a = do
iflag - (#peek struct termios, c_iflag) a
oflag - (#peek struct termios, c_oflag) a
cflag - (#peek struct termios, c_cflag) a
lflag - (#peek struct termios, c_lflag) a
cc - peekArray 20 ((#ptr struct termios, c_cc) a)
ispeed - (#peek struct termios, c_ispeed) a
ospeed - (#peek struct termios, c_ospeed) a
return (Termios iflag oflag cflag lflag cc ispeed ospeed)
poke a (Termios iflag oflag cflag lflag cc ispeed ospeed) = do
(#poke struct termios, c_iflag) a iflag
(#poke struct termios, c_oflag) a oflag
(#poke struct termios, c_cflag) a cflag
(#poke struct termios, c_lflag) a lflag
pokeArray ((#ptr struct termios, c_cc) a) (take 20 (cc ++ repeat 0))
(#poke struct termios, c_ispeed) a ispeed
(#poke struct termios, c_ospeed) a ospeed
foreign import ccall tcgetattr tcgetattr
:: CInt - Ptr Termios - IO CInt
foreign import ccall tcsetattr tcsetattr
:: CInt - CInt - Ptr Termios - IO CInt
setLFlag :: TCFlag - Termios - Termios
setLFlag c a = a { termios_c_lflag = ((termios_c_lflag a) .|. c) }
clearLFlag :: TCFlag - Termios - Termios
clearLFlag c a = a { termios_c_lflag = ((termios_c_lflag a) .. (complement c))
}
setTTYAttr :: CInt - (Termios - Termios) - IO ()
setTTYAttr fd fn = alloca $ \ termiosp - do
status - tcgetattr fd termiosp
if status == 0
then do
termios - peek termiosp
poke termiosp (fn termios)
status - tcsetattr fd (#const TCSAFLUSH) termiosp
if status == 0
then return ()
else throwErrno tcgetattr
else throwErrno tcgetattr
clearICANON = setTTYAttr 0 (clearLFlag (#const ICANON))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to change a process name
Quoth Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) k...@iij.ad.jp, I would like to know how to change a process name in Haskell. When we are programming in C, we can change it by overriding argv on Unix. But I cannot find the same way to do in Haskell. Can anyone suggest how in Haskell? I'm not talking about the result of System.Environment.getProgName but talking about the process name which we can see by the ps command. If you mean, while the program is running - I don't agree that we can change it by overriding argv on UNIX. This might work on some specific operating systems, but not on all of them. I believe POSIX does not specify any way to do this, and in fact there is no reasonably portable way to do it. That's probably why Haskell doesn't support it. Now, if you mean argv[0] in execve(2), through which the caller determines the name for the new process ... I can't explain why Haskell's System.Posix.Process.executeFile doesn't support that, it looks like gratuitous breakage to me. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of aspecific OS thread?
Quoth Jason Dagit dag...@gmail.com, ... Yes. From my perspective (that of a library writer) that's what makes this tricky in GHCi. I need GHCi's cooperation. From GHCi's perspective it's tricky too. It seems to me that ideally, GHCi would do its thing in a child thread, like the extra runtime threads, and let the program execute in the main thread, as in a compiled program. I mean, ideal from the point of view of supporting the general case of library functions that care what the main thread is doing. I'm not saying that's possible - have no idea - but just that where you're dealing with a possibly unconscious and probably poorly documented expectation like that, it's better to not break it in the first place, than to have to try to patch it up at run time. I have been wondering while reading this thread if my Haiku API functions are subject to this restriction - there is an application object that normally runs in main() - but while that would be easy to verify empirically, it wouldn't really tell me what I need to know. A subsequent OS release could easily introduce some thread sensitivity, and I guess if my Haskell programs must run from a child thread under certain circumstances, even if I could make them work I would have to consider that success temporary and provisional. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of aspecific OS thread?
Quoth =?ISO-8859-1?Q?G=E1bor_Lehel?= illiss...@gmail.com, ... Stated another way: I suspect most GUI libraries don't really actually care that you only execute GUI code from the main OS thread, as much as they care that only one (thread-unsafe) GUI function is being called at any given time. If you only ever call GUI code from the same (main) OS thread, that fulfills this requirement, because an OS thread is only capable of running one library function at a time; alternately, if you only ever call GUI code from the same Haskell thread, that also fulfills this requirement, because one Haskell thread is also only capable of running one library function at a time, I thought in the present case, the program now works when compiled, but fails when run in GHCi, and we believe that the only difference here is that GHCi took the main thread and put the program, and hence the GUI, in some other thread? I.e., your requirement is indeed met, per the second alternative, but the program still fails, because this library really does need to execute in the initial main program thread. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context ofaspecific OS thread?
Quoth Brandon Allbery allber...@gmail.com, ... I don't know about the general case, but OS X does treat the main thread specially here; the (native, not X11) framework sets up the connection to Core Graphics in the main thread before invoking the main program, so you can't make whatever it is (thread local storage seems likely) happen in a different thread. For one general case, C++ static constructors run prior to main(), so any thread dependency introduced by a static C++ object would target the initial program thread. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Replacing stdin from within Haskell
Quoth Erik Hesselink hessel...@gmail.com, On Thu, Jun 9, 2011 at 13:40, Neil Davies semanticphilosop...@gmail.com wrote: Anyone out there got an elegant solution to being able to fork a haskell thread and replace its 'stdin' ? If you don't mind being tied to GHC you can use hDuplicateTo from GHC.IO.Handle [1]. You can also use dupTo from the unix package [2], but that ties you to unix-like platforms instead. From reading about it, I would expect hDuplicate to to close and replace the input file descriptor for _all_ threads. Processes are of course the elegant way to separate effects like this. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Quoth Chris Smith cdsm...@gmail.com, That's interesting... whatever the reason, though, I concur that using Haskell seems much easier on Linux and Windows. I had to abandon a plan to introduce Haskell in a class I taught this past semester because of issues with getting it installed on the Macintosh laptops that some of the students had. It's very unfortunate that Haskell on Mac requires software which can neither be bundled in the install kit nor downloaded freely from elsewhere. The part of this that is actually needed is the GCC build system, right? Can't that be bundled on its own in a freely downloadable location? Spoken as a non Mac user... Exactly. If you don't use MacOS, let alone develop on it, I guess it's possible that this looks like an formidable obstacle, but then wouldn't that pose some limits to how much you're going to be able to enjoy GHC anyway? I might be missing something here, since I have never really gotten into the Darwin ports thing, but it seems to me like the real issues confronting Haskell developers on MacOS have to do with access to the Cocoa etc. APIs, and in view of that it seems possibly sort of suicidal to provide an install option that more or less guarantees that no solution to that problem will work (because the free gcc package won't include Cocoa.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OK! I have a Mac with Snow Leopard 10.6.7
Quoth KC kc1...@gmail.com, ... Xcode3.2.6, Haskell Platform 2011.2.0.1 What are 2or 3 ways so far to get a GUI graphics? http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project ... if you don't mind that there will be some Objective C involved. I have written only a very minor application this way, that connects to my IMAP service, retrieves a message by index and part, and displays it in a text window. The network connection and computation is Haskell, so in this case only the absolute minimal Objective C. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Quoth Daniel Peebles pumpkin...@gmail.com, I thought Apple had stopped bundling the dev tools with installation DVDs? Do you have an install DVD with no Xcode on it? I have it on a 10.6 DVD, when would this have happened (or stopped happening)? Quoth Nathan Howell nathan.d.how...@gmail.com, XCode 4 is for sale in the App Store for $5. You do need an account, but not a developer account... so it may be a bit more palatable. But you don't need Xcode 4, do you? The Xcode 3 that comes with the install DVD will work fine! The text on the GHC download page should provide abundant clues to the process and requirements. I think it makes sense to believe what the port maintainer says there, for starters anyway. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. The Web application idea might be a useful workaround for some, like X11 may be acceptable for others, but these could be thought of as exceptions that prove the rule. If that's enough to solve the problem, then there would appear to be little call for Mac GUI applications. My only Haskell application on my ancient PPC Mac uses the terminal, but long ago I tried a Haskell Cocoa library, HOC, that would have supported native graphics, if it had worked for me. Has anyone taken that route with an application? I have been using native API graphics on another more obscure platform (Haiku), of course not portable but much easier to get working than the gigantic cross platform GUI toolkits, and maybe that would address the chicken vs egg problem that helps make Mac GUI apps a non-issue for Haskell. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Quoth wren ng thornton w...@freegeek.org, ... But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones: http://camelbones.sourceforge.net/ Note (again) that there's already some work in this area, http://code.google.com/p/hoc/ My recollection from trying it several years ago was that there must indeed have been something especially cumbersome about it, given the prodigiously long time it would take to build an application, but it could be better now. In any case, I don't think it would be a crime to try a fresh start. With good Haskell-like high-level bindings, or not. If I were to work on it (as I was somewhat inspired to think about after reading Jason Dagit's comments), it would be the thinnest possible layer, with names unchanged and semantics preserved as possible. High level bindings can be applied on top of that, as required. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on a common pattern
Quoth Achim Schneider bars...@web.de, ... I use someIO = f where f Opt1 = ... If it's a common pattern, you can even do opts f _ _ (Opt1 x) = f x opts _ g _ (Opt2 x) = g x opts _ _ h (Opt3 x) = h x . Functions are easier to mess around with than case expressions. I like this ... or, I would like it, if I could make it work! I get The last statement in a 'do' construct must be an expression, if I don't drag the `where' clause down to the end of the `do' block around `someIO', which of course is what we're trying to avoid with the case expression. I must have missed a trick with the layout? Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on a common pattern
Quoth Tillmann Rendel ren...@informatik.uni-marburg.de, ... Where-clauses can only be used on equations, not on expressions or statements, so you would need to float the where clause outwards: So ... not to put too fine a point on it, but ... as useful as function notation could be for the present purposes, you seem to agree that because of syntax limits, where isn't an answer to the problem. Recalling that we were talking about a common pattern v - fx case v of ... ... (where v never appears again) Where a Haskell programmer's reflex seems to call for fx = case ..., or from the old thread mentioned earlier, a lambda with multiple definitions - fx = \ Opt1 - ... Opt2 - ... Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to daemonize a threaded Haskell program?
Quoth Bas van Dijk v.dijk@gmail.com, ... I understand why it's problematic to fork a process which is in the middle of running multiple simultaneous threads. However, in the case of a daemon the fork happens in the beginning of the program. So if I can manage to create a program that first daemonizes my process then starts the Haskell program, all is good. type ProcessID = CInt type Fd = CInt foreign import ccall fork c_fork :: IO CInt foreign import ccall _exit _exit :: CInt - IO () fork :: IO Int - IO ProcessID fork fn = do pid - c_fork if pid == 0 then do fn = _exit . fromIntegral return 0 -- unused, I reckon else if pid 0 then return pid else throwErrno fork System.PosixProcess (exitImmediately) is supposed to be _exit. I would not care to hazard a guess as to whether this will work reliably for you. If you figure out how to use your own custom C main() function, I'd be interested to know. I use separate C programs that exec my Haskell programs. My current GHC can't compile -via-C, but if you can compile a minimal main module to C that way, it probably calls hs_main() or something like that? and you could add your own xx_main() to the stack. Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is there no splitSeperator function inData.List
Quoth Peter Simons sim...@cryp.to, ... having a dictator is not a necessary prerequisite for the ability to make decisions. It's quite possible to decide controversial matters without a dictator -- say, by letting people vote. The problem might be slightly miscast here, as an inability to reach a decision in the face of controversy, and overall I don't think you could make much of a case that Python's development is noticeably more decisive. If you really have 8 candidates for the semantics of separator-split, then even if everyone can bring themselves to agree on one, it's still just one, out of 8 missing functions, and it's fairly understandable that this might not be very appealing. Python also - is different in that function semantics can be conveniently overloaded (I forgot the count parameter, I often want that one - split at the first (n - 1) locations and leave the remainder intact) - is different as a general matter of style and niche - doesn't have our division between String and ByteString - makes it harder and more expensive to implement string.split() Anyway, before it gets to the point where the crowds are camping in the city square and demanding a vote, it might be interesting to see where the code comes down on the matter, so I looked at the hackage source I already happen to have at hand, a measly 252 Haskell source files. I found one (1) separator-split implementation. I was surprised at so few, as I've done it myself several times, so maybe I happen to have an unrepresentative sample? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
