Re: [Haskell-cafe] Regarding Haskell FFI for C/C++ (Passing of String)
Thanks Yves for the reply. The link provided by you is very helpful. Thank you very much. Regards, Rajendra On Thu, Mar 22, 2012 at 7:53 PM, Yves Parès yves.pa...@gmail.com wrote: (Sorry for the double post) Forget about ByteString.Char8: it doesn't handle unicode as it truncates characters. Going from String to bytestring is easy thanks to the utf8-string ( http://hackage.haskell.org/packages/archive/utf8-string/0.3.7/doc/html/Codec-Binary-UTF8-String.html) package and pack function from Data.ByteString(.Lazy). And if you want to convert your String directly to a CString (a Ptr CChar) you better use Foreign.C.String.withCString. Le 22 mars 2012 15:17, Yves Parès yves.pa...@gmail.com a écrit : This joins the question I asked two days ago here. (See http://haskell.1045720.n5.nabble.com/Quickest-way-to-pass-Text-to-C-code-td5582223.html ) Hope that helps. Le 22 mars 2012 15:10, rajendra prasad rajendradpra...@gmail.com a écrit : Hi, I have just started learning Haskell FFI. I am trying to send a string from hastell to a C function. For this, I am required to convert the haskell string to byte string. I have two methods to achieve this task. Both are listed below: 1) import Foreign.C.String let arg1 = map castCharToCChar Hello :: [CChar] 2) import qualified Data.ByteString.Char8 as B f = B.pack Hello I just wanted to know the optimal way to achieve this task. Please suggest the optimal way of doing this. If there is any other way, please share it. Also, please suggest me any good tutorial to start with Haskell FFI for C/C++. Thank you very much. Regards, Rajendra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regarding Haskell FFI
Hi, I am trying to load the DLL(Wrapper.dll) in my code(Main.hs). When I am placing the dll in local directory, I am able to load it through following command: ghci Main.hs -L. -lWrapper But, I am not able to load it if I am putting it in some other directory(../../bin). I used the following command: ghci Main.hs -L../../bin/ -lWrapper I doubt I am not using the correct way to specify the path of dll in the command. Please correct me if I am wrong. Thanks in advance. Regards, Rajendra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reminder Munich Haskell Meeting
Dear all, just to remind you: Tomorrow, 28th of March, our Haskell get-together will take place in Munich. If you plan to join, go to http://www.haskell-munich.de/dates and click the button. Have a nice day, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?
Hello, As vector provides a class generalizing all flavours (Data.Vector.Generic.Vector), it occurs to me that the same could be done for ByteString. Then, packages based on it would have the choice between hardcoded and generic, they wouldn't have to duplicate a module to handle both strict and lazy versions, as (with the exception of functions for communication with C code) they already provide the same API. I would be willing to make it, it's a concern I've had in mind for a long time, but as I'm pretty sure the idea isn't new, I would very much like to know if and what arguments (related to performance maybe ? I don't know...) were raised against that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts-1.12.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.12.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts It's been a long while since the last update before this, but it is my definite hope that I will once again be able to update regularly. This major release primarily enables the (relatively) new quasi-quoter syntax. The major version bump is questionable, but better safe than sorry. The only backwards incompatible change is that pretty- and exact-printing now use the new quasi-quoter syntax, which makes the round-tripping 'exactPrint . parse' cycle fail for code using the old syntax. There are more changes in the pipeline, some larger and some smaller. Stay tuned! Changelog: 1.11.1 -- 1.12.0 === * Move from old [$...| quasi-quote syntax to the new [...| one. The old syntax is still recognized while parsing. * Allow symbols as variables when TypeOperators is enabled. * Rename ExplicitForall in ExplicitForAll, to be consistent with GHC and the Haskell' process. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: haskell-src-exts-1.12.0
On 27 March 2012 11:06, Niklas Broberg niklas.brob...@gmail.com wrote: * Move from old [$...| quasi-quote syntax to the new [...| one. The old syntax is still recognized while parsing. Yay! This makes me more happy than it should. :D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Happstack routing + boomerang + non-ascii urls
Dear Haskell-Cafe, Last weekend I was test driving Web.Routes.Boomerang. A great package … Is there any way I could make it work with urls containing non-ASCII characters? Happstack.Server routing using path handles non-ASCII, as in, for instance, dir work $ path $ workHandler , where workHandler gets a correctly decoded path segment passed in as a String. The following, however, sitemap :: Router Sitemap sitemap = ( rWork . anyString ) passes to Work constructor an incorrectly decoded String. All the plumbing re embedding boomerang route into a normal Happstack one, etc. is done as per example from crash course here: http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang Many thanks, Sem -- Семен Тригубенко signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Happstack routing + boomerang + non-ascii urls
That is concerning and mysterious. In Web.Routes.Happstack we do: let f = runSite (domain `Text.append` approot) siteSpec (map Text.pack $ rqPaths rq) so, boomerang should be using the properly decoded rqPaths from the Happstack Request. Not sure where things are going wrong. I'll look at it soon, when I get a chance. - jeremy On Tue, Mar 27, 2012 at 8:17 AM, Semen Trygubenko se...@trygub.com wrote: Dear Haskell-Cafe, Last weekend I was test driving Web.Routes.Boomerang. A great package … Is there any way I could make it work with urls containing non-ASCII characters? Happstack.Server routing using path handles non-ASCII, as in, for instance, dir work $ path $ workHandler , where workHandler gets a correctly decoded path segment passed in as a String. The following, however, sitemap :: Router Sitemap sitemap = ( rWork . anyString ) passes to Work constructor an incorrectly decoded String. All the plumbing re embedding boomerang route into a normal Happstack one, etc. is done as per example from crash course here: http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang Many thanks, Sem -- Семен Тригубенко -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9xvgEACgkQ3zbainCY8elq4QCeKIM8I3YDCIAKqWgMPtlRkO8W NuYAnjTVpzUSdHwUKNLzczuo4yAPGi1H =iQjy -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Happstack routing + boomerang + non-ascii urls
This should be fixed in happstack-server-6.6.5. You will need to rebuild web-routes-happstack as well to get the changes. Let me know if it works for you! Here is my test app: http://hpaste.org/66072 - jeremy On Tue, Mar 27, 2012 at 8:17 AM, Semen Trygubenko se...@trygub.com wrote: Dear Haskell-Cafe, Last weekend I was test driving Web.Routes.Boomerang. A great package … Is there any way I could make it work with urls containing non-ASCII characters? Happstack.Server routing using path handles non-ASCII, as in, for instance, dir work $ path $ workHandler , where workHandler gets a correctly decoded path segment passed in as a String. The following, however, sitemap :: Router Sitemap sitemap = ( rWork . anyString ) passes to Work constructor an incorrectly decoded String. All the plumbing re embedding boomerang route into a normal Happstack one, etc. is done as per example from crash course here: http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang Many thanks, Sem -- Семен Тригубенко -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9xvgEACgkQ3zbainCY8elq4QCeKIM8I3YDCIAKqWgMPtlRkO8W NuYAnjTVpzUSdHwUKNLzczuo4yAPGi1H =iQjy -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?
On 27 March 2012 11:00, Yves Parès yves.pa...@gmail.com wrote: Hello, As vector provides a class generalizing all flavours (Data.Vector.Generic.Vector), it occurs to me that the same could be done for ByteString. Then, packages based on it would have the choice between hardcoded and generic, they wouldn't have to duplicate a module to handle both strict and lazy versions, as (with the exception of functions for communication with C code) they already provide the same API. I would be willing to make it, it's a concern I've had in mind for a long time, but as I'm pretty sure the idea isn't new, I would very much like to know if and what arguments (related to performance maybe ? I don't know...) were raised against that. It's not entirely what you need but are you aware of my vector-bytestring library? http://hackage.haskell.org/package/vector-bytestring It doesn't (yet) abstract over strict and lazy ByteStrings. But that would be a nice addition! In an ideal world we would have a Lazy type family which for each type of vector would return its lazy version (where the vector is unpacked in the cons cell). Then we would need your generic API for working with both lazy and strict vectors. Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?
Hi Bas,
Yes, thank you to remind me of that, I remember now having seen the project.
Strict ByteStrings being an alias to Vector Word8 is a good idea (are
bytestrings are already implemented exactly like
Data.Vector.Storable.Vector). But in that case we could use the API of
vector for bytestrings (the bytestring API would be provided only for
backwards compatibility, right?).
Does vector-bytestring plans to be the new implementation for bytestrings
in the end or is it a side-package?
In an ideal world we would have a Lazy type family which for each type
of vector would return its lazy version
What about a type like:
data Vector v a = Empty | Chuck {-# UNPACK #-} !(v a) (Vector v a)
??
GHC accepts it.
And then every function for lazy vectors can then be written like:
import qualified Data.Vector.Generic as G (Vector(..))
cons :: (G.Vector v) = a - Vector v a - Vector v a
cons x v = ...
and also (even better):
instance (G.Vector v) = G.Vector (Vector v) where
cons x v = ...
Just make aliases to follow the API, for instance in Data.Vector.Lazy:
import qualified Data.Vector.Lazy.Internal as L
import qualified Data.Vector as V
type Vector a = L.Vector V.Vector a
Le 27 mars 2012 20:38, Bas van Dijk v.dijk@gmail.com a écrit :
On 27 March 2012 11:00, Yves Parès yves.pa...@gmail.com wrote:
Hello,
As vector provides a class generalizing all flavours
(Data.Vector.Generic.Vector), it occurs to me that the same could be done
for ByteString. Then, packages based on it would have the choice between
hardcoded and generic, they wouldn't have to duplicate a module to handle
both strict and lazy versions, as (with the exception of functions for
communication with C code) they already provide the same API.
I would be willing to make it, it's a concern I've had in mind for a long
time, but as I'm pretty sure the idea isn't new, I would very much like
to
know if and what arguments (related to performance maybe ? I don't
know...)
were raised against that.
It's not entirely what you need but are you aware of my
vector-bytestring library?
http://hackage.haskell.org/package/vector-bytestring
It doesn't (yet) abstract over strict and lazy ByteStrings. But that
would be a nice addition!
In an ideal world we would have a Lazy type family which for each type
of vector would return its lazy version (where the vector is unpacked
in the cons cell). Then we would need your generic API for working
with both lazy and strict vectors.
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?
On 27 March 2012 21:46, Yves Parès yves.pa...@gmail.com wrote:
Yes, thank you to remind me of that, I remember now having seen the project.
Strict ByteStrings being an alias to Vector Word8 is a good idea (are
bytestrings are already implemented exactly like
Data.Vector.Storable.Vector). But in that case we could use the API of
vector for bytestrings (the bytestring API would be provided only for
backwards compatibility, right?).
Yes, I hope that one day the bytestring package and the ByteString
type will be deprecated in favor of vector and
Data.Vector.Storable.Vector Word8 respectively. vector-bytestring is
indeed intended as a package which should make the transition easier.
Does vector-bytestring plans to be the new implementation for bytestrings in
the end or is it a side-package?
I hope that once we get on par with bytestring's performance we can
replace it (we're almost there!, Yell if you want to see some
benchmark results).
In an ideal world we would have a Lazy type family which for each type
of vector would return its lazy version
What about a type like:
data Vector v a = Empty | Chuck {-# UNPACK #-} !(v a) (Vector v a)
??
If you build with -Wall you'll see the following unfortunate warning:
Warning: Ignoring unusable UNPACK pragma on the
first argument of `Chunk'
Johan Tibell recently discussed some of his ideas on how to solve this:
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022079.html
But for now we need to make a specialized type for every different
vector type and use an associated type family to abstract over these
different types.
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arguments against an hypothetical Data.ByteString.Generic?
Oh, okay ^^ sorry, my bad. I should have compiled with -Wall.
So I started a repo at https://github.com/YwenP/bytestring-generic
Le 27 mars 2012 22:01, Bas van Dijk v.dijk@gmail.com a écrit :
On 27 March 2012 21:46, Yves Parès yves.pa...@gmail.com wrote:
Yes, thank you to remind me of that, I remember now having seen the
project.
Strict ByteStrings being an alias to Vector Word8 is a good idea (are
bytestrings are already implemented exactly like
Data.Vector.Storable.Vector). But in that case we could use the API of
vector for bytestrings (the bytestring API would be provided only for
backwards compatibility, right?).
Yes, I hope that one day the bytestring package and the ByteString
type will be deprecated in favor of vector and
Data.Vector.Storable.Vector Word8 respectively. vector-bytestring is
indeed intended as a package which should make the transition easier.
Does vector-bytestring plans to be the new implementation for
bytestrings in
the end or is it a side-package?
I hope that once we get on par with bytestring's performance we can
replace it (we're almost there!, Yell if you want to see some
benchmark results).
In an ideal world we would have a Lazy type family which for each type
of vector would return its lazy version
What about a type like:
data Vector v a = Empty | Chuck {-# UNPACK #-} !(v a) (Vector v a)
??
If you build with -Wall you'll see the following unfortunate warning:
Warning: Ignoring unusable UNPACK pragma on the
first argument of `Chunk'
Johan Tibell recently discussed some of his ideas on how to solve this:
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022079.html
But for now we need to make a specialized type for every different
vector type and use an associated type family to abstract over these
different types.
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Happstack routing + boomerang + non-ascii urls
On Tue, Mar 27, 2012 at 01:13:15PM -0500, Jeremy Shaw wrote: This should be fixed in happstack-server-6.6.5. You will need to rebuild web-routes-happstack as well to get the changes. Let me know if it works for you! It does. Thank you very much for your kind and swift help. -- Семен Тригубенко signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mathematics and Statistics libraries
Date: Sun, 25 Mar 2012 17:54:11 +0400 From: Aleksey Khudyakov alexey.sklad...@gmail.com Subject: Re: [Haskell-cafe] Mathematics and Statistics libraries To: haskell-cafe@haskell.org Message-ID: 4f6f2383.6070...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 25.03.2012 14:52, Tom Doris wrote: Hi Heinrich, And of course data visualization. Only library I know of is Chart[1] but I don't like API much. There is the plot[1] library which provides for updateable plots from GHCi REPL and has a gnuplot-like interface. I wrote it for this very reason, a mathematics/statistics development environment. It uses Data.Vector.Storable, which provides for compatability with both statistics and hmatrix packages (as well as hstatistics). I think talking about data frames is a bit pointless unless we specify what is data frame. Basically there are two representations of tabular data structure: array of tuples or tuple of arrays. If you want first go for Data.Vector.Vector YourData. If you want second you'll probably end up with some HList-like data structure to hold arrays. Matrices from hmatrix are easily converted to rows or columns of Data.Vector.Storable and can be sliced and otherwise manipulated. [1] http://hackage.haskell.org/package/plot%20%20[1]%20http://hackage.haskell.org/package/plot Vivian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fail-back monad
Hi Haskellers.
In my package MFlow [1] I program an entire web navigation in a
single procedure. That happened in the good-old WASH web application
framework.
The problem is the back button in the Browser.
To go back in the code to the previous interactions when the data
input does not match the expected because the user pressed the back
button one or more times, i came across this Monad specimen,: that
solves the problem.
data FailBack a = BackPoint a -- will go back to this point
| NoBack a . -- Normal outcome
| GoBack-- exception:: must
go to the last backPoint
newtype BackT m a = BackT { runBackT :: m (FailBack a ) }
-- this monad nas a loop
instance Monad m = Monad (BackT m) where
fail _ = BackT $ return GoBack
return x = BackT . return $ NoBack x
x = f = BackT $ loop
where
loop = do
v - runBackT x
case v of
NoBack y - runBackT (f y) -- business as usual
BackPoint y - do
z - runBackT (f y)
case z of
GoBack - loop -- if x was a backpoint,
then redirects the flow to this backpoint
other - return other
GoBack - return GoBack --propagate the signal back
This monad does not perform exploration of alternatives as is the
case of MonadPlus instances. It does not perform the kind of
backtracking of nondeterministic three navigations in the Prolog
style. It just go back to the last point where the computation can
restart again in a sequence of actions.
In this example:
liftBackPoint f= BackT $ f = \x - return $ BackPoint x
test= runBackT $ do
lift $ print will not return back here
liftBackPoint $ print will return here
n2 lt;- lift $ getLine
lift $ print second input
n3 lt;- lift $ getLine
if n3 == back
then fail
else lift $ print $ n2++n3
Whenever the second input is back The procedure will go back to
where liftBackPoint is. Otherwise, it will return the concatenation of
the two inputs. If the underlying monad is an instance of MonadState,
it can transport the state that caused the failure to the backpoint.
Are there something similar? May it be functionally equivalent to
something simpler or with more grounds?
I looked at some exception monads out there, but they did not seems
to share the same idea
[1]
http://haskell-web.blogspot.com.es/2012/02/web-application-server-with-stateful.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
