Re: OS X framework + ghci linker + RTS flags = bus error?
gcc -c BusErr.m ghci -framework Foundation +RTS -RTS BusErr.o Loading package base ... linking ... done. Loading object (static) BusErr.o ... done Loading object (framework) Foundation ... done final link ... Bus error Now that is interesting. I can reproduce that on my machine, and I'll investigate it. Also note that you should avoid loading Objective C .o files into GHCi at all costs anyway, because GHCi's Linker does not support Objective C and therefore won't initialise classes, resolve selectors etc. Anything more complex than NSLog will probably fail. When you have Objective C code, put it into a dynamic library and load that from GHCi. I do not think that your current problem is related to this, but you're bound to run into this next. So you've been warned ;-). Cheers, Wolfgang ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1035575 ] Parallel array comprehension related crash
Bugs item #1035575, was opened at 2004-09-27 19:33
Message generated for change (Comment added) made by ekarttun
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1035575group_id=8032
Category: Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Einar Karttunen (ekarttun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parallel array comprehension related crash
Initial Comment:
The following code panics with both 6.2 and the Debian
ghc-cvs snapshot. The problem appears to be in
the comprehension.
{-# OPTIONS -fparr -fglasgow-exts #-}
module Main (main) where
import GHC.PArr
ary = let arr1 = toP [1..10]
arr2 = toP [1..10]
f = [: i1 + i2 | i1 - arr1 | i2 - arr2 :]
in f !: 1
main = print ary
and the error (from the cvs snapshot):
ghc-6.3: panic! (the `impossible' happened, GHC version
6.3):
applyTypeToArgs
GHCziPArr.mapP{v} {- 01l -}
@ (GHCziBase.Z0T{tc} {- (w) 40 -},
GHCziNum.Integer{tc} {- 314 -})
(\ (ds{v}_d1On T :: (GHCziBase.Z0T{tc} {- (w) 40 -},
GHCziNum.Integer{tc} {- 314
-})) -
case ds{v}_d1On
of wild{v}_B1 T { (ds{v}_d1Ot T, i2{v} {- v
aAO -} T) -
case ds{v}_d1Ot of wild{v}_B1 T { () -
let {
ds{v}_d1OB T :: GHCziBase.Z0T{tc} {- (w) 40 -}
ds{v}_d1OB = __letrec { } in
GHCziBase.Z0T{v} {- (w) 71 -}
} in (ds{v}_d1On, ds{v}_d1OB)
}
})
(GHCziPArr.crossP{v} {- 01o -}
@ GHCziBase.Z0T{tc} {- (w) 40 -}
@ GHCziNum.Integer{tc} {- 314 -}
(GHCziPArr.replicateP{v} {- 01k -}
@ GHCziBase.Z0T{tc} {- (w) 40 -}
(GHCziBase.Izh{v} {- (w) 6d -} 1)
GHCziBase.Z0T{v} {- (w) 71 -})
(GHCziPArr.filterP{v} {- 01m -}
@ GHCziNum.Integer{tc} {- 314 -}
(\ (ds{v}_d1Oj T :: GHCziNum.Integer{tc} {-
314 -}) -
let {
i2{v} {- v aAO -} T ::
GHCziNum.Integer{tc} {- 314 -}
i2{v} {- v aAO -} = ds{v}_d1Oj
} in GHCziBase.True{v} {- (w) 6v -})
arr2{v} {- v aAA -}))
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
--
Comment By: Einar Karttunen (ekarttun)
Date: 2004-10-22 02:42
Message:
Logged In: YES
user_id=665422
With ghc-6.2.2 one gets:
ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2):
Name.mkTupNameStr: 1 ???
And with the cvs-snapshot from 20041017 undefined references:
aa.o(.text+0x367): In function `s1TL_info':
: undefined reference to `DataziTuple_Z1T_con_info'
aa.o(.text+0x5e7): In function `s1TV_info':
: undefined reference to `DataziTuple_Z1T_con_info'
collect2: ld returned 1 exit status
--
Comment By: Einar Karttunen (ekarttun)
Date: 2004-09-27 19:45
Message:
Logged In: YES
user_id=665422
The cvs version packaged with debian is quite old:
[EMAIL PROTECTED]:~$ dpkg -s ghc-cvs | grep Version
Version: 20040725-2
I can try to compile a newer ghc if that would potentially help.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1035575group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Template Haskell...
MR K P SCHUPKE wrote: Thanks for the URL... I have realised I jumped the gun saying the derivation can be done in template-haskell... there is one small problem: $(derive [t| SomeConstructor a b |]) passes the constructor to derive... is there any way to get the type information for some type? You can do $(derive [d| data X a b = X1 a b |]) Is there any way to get the same information from something like: $(derive2 [T| X a b |]) You would have to say $(derive (reifyDecl X)) / Ulf ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mutable hash?
Title: Mutable hash? Does anybody know about a mutable hash implementation for ghc? There is going to be a lot of updates in the hash (some millions adds and removes) so a non-mutable structure will not do?! Cheers, Petter ###This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.For more information, connect to http://www.F-Secure.com/___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mutable hash?
There is a hashtable in the IO monad: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.HashTable.html I understand there was an important bugfix that went into 6.2.2 for this hashtable implementation, so you'll probably want to make sure to use the latest GHC if you'll be using this. Petter Egesund wrote: Does anybody know about a mutable hash implementation for ghc? There is going to be a lot of updates in the hash (some millions adds and removes) so a non-mutable structure will not do?! Cheers, Petter ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
SV: Mutable hash?
Thanks! Petter -Opprinnelig melding- Fra: Robert Dockins [mailto:[EMAIL PROTECTED] Sendt: 21. oktober 2004 15:17 Til: Petter Egesund Kopi: [EMAIL PROTECTED] Emne: Re: Mutable hash? There is a hashtable in the IO monad: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.HashTabl e.html I understand there was an important bugfix that went into 6.2.2 for this hashtable implementation, so you'll probably want to make sure to use the latest GHC if you'll be using this. Petter Egesund wrote: Does anybody know about a mutable hash implementation for ghc? There is going to be a lot of updates in the hash (some millions adds and removes) so a non-mutable structure will not do?! Cheers, Petter ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ -- -- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Top level mutable data structures problem
On Wed, Oct 20, 2004 at 03:46:47PM +0100, Simon Marlow wrote: I liked the original idea. I'm not sure if I agree with the argument that allowing fully-fledged IO actions in the initialisation of a module is unsafe. I agree that it is a little opaque, in the sense that one can't easily tell whether a particular init action is going to run or not. Allowing IO actions in the initialization of a module then requires the ability to determine what order these initializations happen in. Ocaml does this, and it requires that all modules be specified in a proper order to the compiler. Dave ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Top level mutable data structures problem
On Wed, Oct 20, 2004 at 04:38:54PM +0100, Simon Peyton-Jones wrote: * When a program is started, the module initialisation actions of its modules run, in an order that respects module dependencies. What happens when there are cicular dependencies between modules. Perhaps the circular dependency is only because of sharing of types, and there is a valid order for the initialization. But, is it easy for the compiler to determine this? Dave ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: CVS HEAD ghc fails with Panic!
Simon, I had answered to your e-mail almost two days ago, then I resent my reply today, but apparently my e-mail doesn't reach you! I see that it was delivered correctly here on my machine: Oct 21 18:56:51 peti sm-mta[11337]: i9LGunqM011335: to=[EMAIL PROTECTED],[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1000/100), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=61578, relay=mailc.microsoft.com. [207.46.121.52], dsn=2.0.0, stat=Sent ( [EMAIL PROTECTED] Queued mail for delivery) Maybe the Microsoft mail server doesn't like me? Anyway, here is the URL you needed to check the bug report: http://cryp.to/hsemail/hsemail-2004-10-12.tar.gz Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mutable hash?
G'day. Quoting Petter Egesund [EMAIL PROTECTED]: Does anybody know about a mutable hash implementation for ghc? How about three of them? http://cvs.sourceforge.net/viewcvs.py/haskell-libs/libs/hashtable/ They're all concurrency-safe. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] readList oddity
recently I was surprised by readList's behaviour (I'm no implying it is wrong). Look at this: data R = R deriving Show instance Read R where readsPrec p cs = do ( x, cs' ) - lex cs case x of R - return (R, cs') _ - error no R that is, we have a very eager parser: if it does not accept the token, it will raise an exception. now - which of the following will work? check0 :: [R] check0 = read [ ] check1 :: [R] check1 = read [ R ] check2 :: [R] check2 = read [ R, R ] turns out that check1 and check2 work, but check0 will not (I thought it would). The implementation (in the Prelude) seems to think that ] (in check0) could possibly be the beginning of a list element. -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] readList oddity
Am 21.10.2004 um 09:55 schrieb Johannes Waldmann: turns out that check1 and check2 work, but check0 will not (I thought it would). The implementation (in the Prelude) seems to think that ] (in check0) could possibly be the beginning of a list element. This is just a problem of non-deterministic parsing. The prelude's read function always explores all possible parses (in order to flag ambiguous ones). Thus, at the beginning of the list it will always try to match the input against ] and an element causing check0 to fail. For later elements there is no problem because the choice is between ] and ,. Because of that, calling error in one of your read functions seems a bad idea. In fact, returning an empty list is the right way to return an error in the prelude's parsing framework. If you want something different (e.g., because you want better error messages) you should not be using the prelude's read function. IMHO, the prelude's Read class for that reason is quite useless -- except for converting strings into numbers. Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] readList oddity
Because of that, calling error in one of your read functions seems a bad idea. In fact, returning an empty list is the right way to return an error in the prelude's parsing framework. If you want something different (e.g., because you want better error messages) you should not be using the prelude's read function. indeed I use Parsec in this project, because of better error reporting, and because it evaluates more eager. But in this case an external library (Wash) was expecting that I provide a Read instance. I now think I should have overridden the default definition of readList. http://141.57.11.163/cgi-bin/cvsweb/lib/Autolib/Reader/Link.hs?rev=1.2 -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ICEIS'2005: Workshop on Ubiquitous Computing IWUC'2005
[Apologies if you have received multiple postings] CALL FOR PAPERS International Workshop on Ubiquitous Computing (IWUC 2005)May 24-25, 2005 - Miami, USA In conjunction with the Seventh International Conference on Enterprise Information Systems - ICEIS 2005 (http://www.iceis.org/) Workshop Background and GoalsThe development and availability of new computing and communication devices, and the increased connectivity between these devices, thanks to wired and wireless networks, are enabling new opportunities for people to perform their operations anywhere and anytime. Furthermore, due to the high acceptance rate of such devices by the user community, it is expected that these devices will become so pervasive that most users will take them for granted. Generally known as Ubiquitous Computing (UC), the vision of UC is to push computational services out of conventional desktop interfaces into environments characterized by transparent forms of interactivity.Despite the growing interest in UC, there is still some progress to be made before UC shifts from the research mode to the commercial and intensive use modes. The support technologies, however, are improving at an impressive pace. Most of the research and development activities are currently aimed at improving the devices themselves and the technologies these devices will use to communicate. At present, the main use of mobile devices is still voice-oriented, but several indicators show that this is changing. 3G networks (e.g., GPRS, UMTS) and recent development of communication and presentation protocols (e.g., XML, WAP) are being combined to give users a high-quality experience of data-centric services.Besides the central role that hardware infrastructure plays in the expansion and penetration of UC, other issues still need to be tackled to better assist developers of UC applications. Developers are put on the front line of satisfying the promise of businesses and service providers for delivering Internet content to mobile devices. Indeed, the fact that an application for mobile users has different requirements, calls for new techniques to identify and specify these requirements. With regard to users, it is expected that they will be frequently engaged in complex operations such as searching the net for better business opportunities. Therefore, their association with intelligent components, to act as proxies, is deemed appropriate. UC environments of the near future will be populated by a large number of computing devices, spread across the network, and often invisible. These devices need to be coordinated for better interactions. Devices, whether carried on by people or embedded into other systems (within the home or at other sites), will constitute a global networking infrastructure -- and likely to provide a new level of openness and dynamics. These interactions raise many new issues that draw upon existing research areas, as well as introduce new research and development challenges, in technical areas (such as device design, wireless communication, location sensing, etc), psychology (privacy concerns, attention focus, multi-person interaction, etc), and design (direct interaction, work patterns, etc).Existing global efforts in Grid Computing also shares some similarities with the aims of this workshop, although Grid computing at present is restricted to high-end computational resources. Making the Grid more open, and accessible to a wider range of users will also require the need to address similar challenges.Topics of interestIn this workshop, we aim to identify ecent and significant developments in the general area of ubiquitous computing. Topics of interests include, but are not limited to:- Mobile computing vs. Pervasive computing vs. Ubiquitous computing.- Design methodologies and evaluation techniques.- New interfaces and modes of interactions between people and ubiquitous computing devices, applications or environments.- Grid Computing technologies for Wireless networks- Context awareness.- Agent-based ubiquitous applications.- Services for ubiquitous applications.- Middleware for service discovery.- Integration of wired and wireless networks.- Enabling technologies such as Bluetooth, 802.11, etc.- Security and privacy issues.- Visionary future scenarios.- Mobile services- Performance tuning of mobile applicationsFormat of the WorkshopThe workshop will consist of oral presentations. The proceedings of the workshop will be published in the form of a book by ICEIS. Submission of PapersThere will be two types of papers: long (approx. 5000 words) and short (approx. 2000 words). Furthermore, a keynote speaker and a discussion panel are planned. Postscript/RTF versions of the manuscript should be submitted thru ICEIS web-based paper submission
Re: [Haskell-cafe] Stream processors
Peter Simons wrote:
type Buffer = (Ptr Word8, Int)
data StreamProc ctx a
= SP
{ start :: IO ctx
, feed :: ctx - Buffer - IO ctx
, commit :: ctx - IO a
}
Must contexts be used in a single-threaded manner? If so, I would expect
this interface:
start :: IO ctx
feed :: ctx - Buffer - IO ()
commit :: ctx - IO a
If not, I would expect this interface:
start :: ctx
feed :: ctx - Buffer - IO ctx
commit :: ctx - a
Additionally, I don't think (Ptr Word8, Int) is general enough for all reasonable uses
of this interface. For example, there's nothing inherently unsafe about calculating
the MD5 hash of the contents of an STUArray or UArray:
feedBuffer :: ctx - Buffer - IO ctx
feedSTUArray :: ctx - STUArray s Int Word8 - ST s ctx
feedUArray :: ctx - UArray Int Word8 - ctx
And what about a subrange of an STUArray or UArray? These are the problems I ran into
when trying to produce a useful MD5 library for Haskell. I feel the same way as you --
that there should be a standard way of doing this -- but I don't think the three
functions you propose are nearly enough.
-- Ben
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stream processors
This is the interface I came up with (and its fairly efficient): data IList a i e = ICons i i (a i e) (IList a i e) | INil class List l e where nil :: l e null :: l e - Bool head :: l e - e tail :: l e - l e (+:) :: e - l e - l e class List (l a i) e = ListPlus l a i e where (++:) :: a i e - l a i e - l a i e part :: a i e - i - l a i e - l a i e Here's the instance for a normal list: instance List [] e where nil = [] null (_:_) = False null _ = True head (a:_) = a head _ = error head: empty list tail (_:l) = l tail _ = error tail: empty list a +: l = a:l Here's the instance for a list made of UArray buffers: instance (IArray a e,Ix i,Num i) = List (IList a i) e where nil = INil null INil = True null _ = False head (ICons i _ a _) = a!i head _ = error head: empty list tail (ICons i j a l) | i j = ICons (i+1) j a l | otherwise = l tail _ = error tail: empty list a +: l = ICons 0 0 (array (0,0) [(0,a)]) l instance (IArray a e,Ix i,Num i) = ListPlus IList a i e where a ++: l | e = s = ICons s e a l | otherwise = l where ~(s,e) = bounds a part a i l | e = i = ICons s i a l | otherwise = l where ~(s,e) = bounds a Here's a feeder reading from a file: hGetIList :: ListPlus l UArray Int Word8 = Int - Handle - IO (l UArray Int Word8) hGetIList bufSize h = do mt - newArray_ (0,bufSize-1) ioLoop mt where ioLoop mt = unsafeInterleaveIO $ do sz - hGetArray h mt bufSize hd - freeze mt case sz of 0 - return nil n | n bufSize - do return (part hd (n-1) nil) | otherwise - do tl - ioLoop mt return (hd ++: tl) And here's an example consumer: wc :: List l Word8 = l Word8 - Char - Int - Int - Int - (Int,Int,Int) wc l p i j k | p `seq` i `seq` j `seq` k `seq` False = undefined | not $ Main.null l, h - (toEnum . fromEnum . Main.head) l, t - Main.tail l = case isSpace h of False - wc t h (i + 1) (j + if isSpace p then 1 else 0) k _ - wc t h (i + 1) j (k + if h == '\n' then 1 else 0) | otherwise = (i,j,k) Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
Ben Rudiak-Gould writes: Must contexts be used in a single-threaded manner? If so, I would expect this interface: start :: IO ctx feed :: ctx - Buffer - IO () commit :: ctx - IO a 'feed' cannot have this signature because it needs to update the context. If not, I would expect this interface: start :: ctx feed :: ctx - Buffer - IO ctx commit :: ctx - a Both 'start' and 'commit' need to be in the IO monad, because creating and finalizing the context may involve IO calls. (Just think of a computation that does internal buffering in memory which is accessed through another Ptr.) Additionally, I don't think (Ptr Word8, Int) is general enough for all reasonable uses of this interface. That's true. I used this because I have the data in a memory buffer already, so this is the API with the best performance for me because it handles the input without marshaling. I agree it would be nice to have something more general and generally smarter than the my type definition -- that's why I asked on the list. :-) feedBuffer :: ctx - Buffer - IO ctx feedSTUArray :: ctx - STUArray s Int Word8 - ST s ctx feedUArray :: ctx - UArray Int Word8 - ctx I would implement feedSTUArray and friends as wrappers around the Ptr interface, not as primitive computations of the stream processor. But nonetheless, having those would be nice. Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
K P SCHUPKE writes: This is the interface I came up with (and its fairly efficient): data IList a i e = ICons i i (a i e) (IList a i e) | INil Isn't that an interface for doing fast I/O rather than for writing stream processors? If I look at the consumer: wc :: List l Word8 = l Word8 - Char - Int - Int - Int - (Int,Int,Int) I don't see how the IList data type would help writing the wc function. Where is the advantage over data CountingState = ST !Bool !Int !Int !Int wc :: Char - CountingState - CountingState ...? Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Stream processors
Okay, maybe I misunderstood, I thought by stream processors you meant functions of the type: process :: [a] - [a] where both the input and the output are lazy lists (streams) I would assume if you want to have a stateful filter you need to maintain the state by using either: process :: [a] - IO [a] process :: state - [a] - [a] process :: [a] - ST s [a] Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Stream processors
Peter Simons wrote: Ben Rudiak-Gould writes: Must contexts be used in a single-threaded manner? If so, I would expect this interface: start :: IO ctx feed :: ctx - Buffer - IO () commit :: ctx - IO a 'feed' cannot have this signature because it needs to update the context. Sure it can -- it's just like writeIORef :: IORef a - a - IO (). If the return of writeIORef were IO (IORef a) instead, it would be confusing: does it return the same IORef or a different one? If a different one, does the original one remain unchanged? If the same one, why bother returning it when the caller already had it? That's what confused me about your proposed interface. If not, I would expect this interface: start :: ctx feed :: ctx - Buffer - IO ctx commit :: ctx - a Both 'start' and 'commit' need to be in the IO monad, because creating and finalizing the context may involve IO calls. (Just think of a computation that does internal buffering in memory which is accessed through another Ptr.) In this interface contexts are supposed to be immutable Haskell values, so there's no meaning in creating new ones or finalizing old ones. The initial empty context is just a value, and the final MD5 hash (or whatever) is a pure function of the final context. Yes, this would likely involve internal use of unsafePerformIO in the implementation, but that's what it's there for (a required part of the FFI). Dealing with reuse of state might also make the library too inefficient in practice, which would be a bigger problem. feedBuffer :: ctx - Buffer - IO ctx feedSTUArray :: ctx - STUArray s Int Word8 - ST s ctx feedUArray :: ctx - UArray Int Word8 - ctx I would implement feedSTUArray and friends as wrappers around the Ptr interface, not as primitive computations of the stream processor. I think it's impossible to do this safely, but it would be great if I were wrong. -- Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
K P SCHUPKE writes: Okay, maybe I misunderstood, I thought by stream processors you meant functions of the type: process :: [a] - [a] No, my stream processors currently have the API I described in my initial posting. What I was wondering is whether there is a more general API that I could use to unify all kinds of stream processors into a class of data types which my IO driver can use without having to know what it is. The StreamProc data type I defined does that, but I suspect that there is something more fundamental definition than what I've come up with. Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
Ben Rudiak-Gould writes: start :: IO ctx feed :: ctx - Buffer - IO () commit :: ctx - IO a 'feed' cannot have this signature because it needs to update the context. Sure it can -- it's just like writeIORef :: IORef a - a - IO (). I guess it's mood to argue that point. I don't want a stream processor to have a global state, so using an internally encapsulated IORef is not an option for me. I am looking for an more _general_ API, not one that forces implementation details on the stream processor. That's what my StreamProc data type does already. :-) start :: ctx feed :: ctx - Buffer - IO ctx commit :: ctx - a In this interface contexts are supposed to be immutable Haskell values, so there's no meaning in creating new ones or finalizing old ones. I don't want to restrict the API to immutable contexts. A context could be anything, _including_ an IORef or an MVar. But the API shouldn't enforce that. I would implement feedSTUArray and friends as wrappers around the Ptr interface, not as primitive computations of the stream processor. I think it's impossible to do this safely, but it would be great if I were wrong. wrap :: (Storable a, MArray arr a IO) = Ptr a - Int - IO (arr Int a) wrap ptr n = peekArray n ptr = newListArray (0,n) Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
K P SCHUPKE writes: My point was... using the IO library I posted which abstracts the buffer management, you can treat the IO as a simple list... Do you happen to have a ready-to-run word-counting example for me which is based on your library? I've tried to compile the code you posted, but GHC won't let me use hGetIList with the following error: No instance for (ListPlus l UArray Int Word8) arising from use of `hGetIList' at /tmp/test.hs:82:7-15 I'd be interested in comparing the performance of IList with the I/O library I've written. Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stream processors
At 21 Oct 2004 16:48:57 +0200, Peter Simons wrote: Hi, I know the stream processors as described in Hughes' paper about Arrows, but those are pure stream processors -- they don't allow for I/O, which I need to handle the Ptr. Here is a some code I scraped off the net a while ago, though I can't seem to find the origin anymore. Not sure what the license is. Also, I think it might be a little buggy -- I have not used it much... However, it does show how to do IO in stream processing arrows... module ArrowStream where - -- -- Definition of continuation based stream processor as an arrow -- -- Reference: Magnus Carlsson, Thomas Hallgren, Fudgets--Purely Functional --Processes with applications to Graphical User Interfaces, --Department of Computing Science, Chalmers University of --Technology, Goteborg University, Dissertation 1998 -- --John Hughes, Generalising Monads to Arrows, November 10, 1998 -- -- History: 14-Aug-2002 Shawn Garbett, Creation --01-Apr-2004 A -- --- import Char import Control.Arrow import Control.Concurrent import Monad import System.IO data SP i o = Put o (SP i o) | Get (i - SP i o) | Null | DoIO (IO (SP i o)) instance Arrow SP where arr f = Get (\x - Put (f x) (arr f)) sp1 Put c sp2 = Put c (sp1 sp2) Put b sp1 Get f = sp1 f b Get f1 Get f2 = Get (\a - f1 a Get f2) _ Null = Null Null Get _ = Null -- Process io downstream first sp DoIO io = DoIO (Monad.liftM (sp ) io) -- Process io upstream next DoIO io sp = DoIO (Monad.liftM ( sp) io) first f = bypass [] f where bypass ds (Get f) = Get (\(b,d) - bypass (ds++[d]) (f b)) bypass (d:ds) (Put c sp) = Put (c,d) (bypass ds sp) bypass [] (Put c sp) = Get (\(b,d) - Put (c,d) (bypass [] sp)) -- making it up... bypass ds (DoIO iosp) = DoIO (iosp = (\sp - return (bypass ds sp))) instance ArrowZero SP where zeroArrow = Get (\x - zeroArrow) instance ArrowPlus SP where Put b sp1 + sp2 = Put b (sp1 + sp2) sp1 + Put b sp2 = Put b (sp1 + sp2) Get f1 + Get f2 = Get (\a - f1 a + f2 a) sp1 + (DoIO ioSP) = DoIO (ioSP = (\sp2 - return (sp1 + sp2))) (DoIO ioSP) + sp2 = DoIO (ioSP = (\sp1 - return (sp1 + sp2))) sp1 + Null = sp1 Null + sp2 = sp2 instance ArrowChoice SP where left (Put c sp) = Put (Left c) (left sp) left (Get f) = Get (\z - case z of Left a - left (f a) Right b - Put (Right b) (left (Get f))) left (DoIO iosp) = DoIO (iosp = return . left) -- | Run the IO in a DoIO -- | the putStrLn's are just for debug... spIO :: Show o = SP i o - IO () spIO sp = case sp of Null - putStrLn Null return () Get _ - putStrLn (Get f) return () Put n sp' - putStrLn (Put ++ (show n)) spIO sp' DoIO io- io = spIO ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
Jeremy Shaw writes: Here is a some code I scraped off the net a while ago, though I can't seem to find the origin anymore. I _think_ it is from part of Fudgets library: http://www.cs.chalmers.se/Cs/Research/Functional/Fudgets/ Thanks for posting it, though, this implementation is rather neat. Now I merely need to think of a way to apply this code to my problem. :-) Perhaps some more paper-reading is in order ... Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] existential type problem
On Sat, Oct 16, 2004 at 05:54:46AM +, [EMAIL PROTECTED] wrote: data Bar a m = forall t. (MonadTrans t, Monad (t m)) = Bar (t m a - m a) (t m Int) data Foo = Foo (forall a m. Monad m = Bar a m) Is it true that I cannot have a function foo run op = Foo (Bar run op) because it does not have an expressible type? Or is there some way to make ghc accept this? Obviously, this expression can be used in the context of a larger expression. myFoo :: Int - Foo myFoo i = Foo (Bar run op) where run :: Monad m = StateT Int m a - m a run prog = do (a, s) - runStateT prog i return a op :: Monad m = StateT Int m Int op= get Andrew ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stream processors
Ben Rudiak-Gould writes: bar :: StreamProc ctx a - IO (a,a) bar sp = do ctx - start sp (ptr1,n1) - ... (ptr2,n2) - ... ctx1 - feed sp ctx (ptr1,n1) ctx2 - feed sp ctx (ptr2,n2) val1 - commit sp ctx1 val2 - commit sp ctx2 return (val1,val2) Ah! Now I understand what you meant with single-threaded versus multi-threaded use of the stream processor. Well, in the general case the result would be undefined, because not every stream processor allows a context to be re-used. The SHA1 implementation I use, for example, has a context of Ptr Sha1Context ..., so both val1 and val2 would be the hash of the concatenation of both buffers. Which is not what you'd expect. A different implementation, on the other hand, might give you the hash of the first and second block respectively. Hmmm. So I have those options: (1) If you want to use _any_ stream processor, you must use it single-threadedly. If you use it multi-threadedly, you have to know what you're doing. (2) Have distinct types (or classes) for stream processors that allow the context to be re-used and for those which do not. So far, I've implicitly used (1). Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
