Re: [Haskell-cafe] ANNOUNCEMENT: nehe-tuts 0.2.0, new release

[Vo Minh Thu]

2011/3/28 Jason Dagit :
> ...
> The tutorials are still written using OpenGL's immediate
> mode, but that was deprecated in OpenGL 3.x so it's possible that in the
> future these examples won't be supported by your graphics card.
> ...

Hi,

I wouldn't worry about the older API to be unsupported in the
foreseeable future. This is precisely the reason OpenGL is a bit slow
to evolve its API. At least nVidia made it clear they won't remove
support for older versions, I guess AMD is in the same boat.

Cheers,
Thu

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: Google Summer of Code student application period opens today

[Johan Tibell]

Hi,

The Google Summer of Code student application period starts today at
19:00 UTC. If you're a student and like to get paid to work on a
Haskell project this summer I recommend you go find an interesting
project [1] and start working on your application. You can find more
information on the wiki [2].

Cheers,
Johan

1. http://hackage.haskell.org/trac/summer-of-code/report/1
2. http://hackage.haskell.org/trac/summer-of-code/wiki/Soc2011

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[John Millikin]

On Sunday, March 27, 2011 9:45:23 PM UTC-7, Ertugrul Soeylemez wrote:
>
> > For setting a global timeout on an entire session, it's better to wrap
> > the ``run_`` call with ``System.Timeout.timeout`` -- this is more
> > efficient than testing the time on every chunk, and does not require a
> > specialised enumerator.
> It may be more efficient, but I don't really like it.  I like robust
>
> applications, and to me killing a thread is always a mistake, even if
> the thread is kill-safe.
>
``timeout`` doesn't kill the thread, it just returns ``Nothing`` if the 
computation took longer than expected.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[David Leimbach]

On Mon, Mar 28, 2011 at 8:06 AM, John Millikin  wrote:

> On Sunday, March 27, 2011 9:45:23 PM UTC-7, Ertugrul Soeylemez wrote:
>>
>> > For setting a global timeout on an entire session, it's better to wrap
>> > the ``run_`` call with ``System.Timeout.timeout`` -- this is more
>> > efficient than testing the time on every chunk, and does not require a
>> > specialised enumerator.
>> It may be more efficient, but I don't really like it.  I like robust
>>
>> applications, and to me killing a thread is always a mistake, even if
>> the thread is kill-safe.
>>
> ``timeout`` doesn't kill the thread, it just returns ``Nothing`` if the
> computation took longer than expected.
>


Timeout does kill the thread that is used for timing out :-).  The
thread that measures the timeout throws an exception to the worker
thread that's being monitored.

Either way you're interrupting a thread.  Kill it or toss an exception
at it, I don't see the difference really.

Dave



>
> ___
> 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] bug in Prelude.words?

[malcolm.wallace]

Does anyone else think it odd that Prelude.words will break a string at a non-breaking space?Prelude> words "abc def\xA0ghi"["abc","def","ghi"]I would have expected this to be the obvious behaviour: Prelude> words "abc def\xA0ghi"["abc","def\160ghi"]Regards,Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[Colin Adams]

It doesn't seem odd to me.

Consider an HTML page with that "sentence" displayed on it. If you ask the
viewer of the page how many words are in the sentence, then surely you will
get the answer 3?

On 28 March 2011 16:55, malcolm.wallace  wrote:

> Does anyone else think it odd that Prelude.words will break a string at a
> non-breaking space?
>
> Prelude> words "abc def\xA0ghi"
> ["abc","def","ghi"]
>
> I would have expected this to be the obvious behaviour:
>
> Prelude> words "abc def\xA0ghi"
> ["abc","def\160ghi"]
>
> Regards,
> Malcolm
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Colin Adams
Preston, Lancashire, ENGLAND
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[Christopher Done]

On 28 March 2011 17:55, malcolm.wallace  wrote:

> Does anyone else think it odd that Prelude.words will break a string at a
> non-breaking space?
>
> Prelude> words "abc def\xA0ghi"
> ["abc","def","ghi"]
>

I think it's predictable, isSpace (which words is based on) is based on
generalCategory, which returns the proper Unicode category:

λ> generalCategory '\xa0'
Space

So:

-- | Selects white-space characters in the Latin-1 range.-- (In
Unicode terms, this includes spaces and some control
characters.)isSpace :: Char -> Bool-- isSpace includes
non-breaking space-- Done with explicit equalities both for
efficiency, and to avoid a tiresome-- recursion with GHC.List
elemisSpace c   =  c == ' ' ||
  c == '\t'||   c == '\n'||
   c == '\r'||   c == '\f'
||   c == '\v'||
c == '\xa0'  ||   iswspace (fromIntegral (ord
c)) /= 0
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[malcolm.wallace]

Consider an HTML page with that "sentence" displayed on it. If you ask the viewer of the page how many words are in the sentence, then surely you will get the answer 3? But what about the author?  Surely there is no reason to use a non-breaking space unless they intend it to mean that the characters before and after it belong to the same logical unit-of-comprehension?Regards,    Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[James Cook]

On Mar 28, 2011, at 12:54 AM, wren ng thornton wrote:


On 3/27/11 9:58 PM, John Millikin wrote:
Resending is slightly more complex -- if the other end can say  
"resend that
last chunk", then it should be easy enough, but "resend the last 2  
bytes of
that chunk you sent 5 minutes ago" would be much harder. What is  
your use

case?


This does highlight one of the restrictions I've lamented about the  
iteratee framework. Namely that the current versions I've seen place  
unnecessary limitations on the communication the iteratee is allowed  
to give to the enumerator/enumeratees above it. This is often  
conflated with the iteratee throwing an error/exception, which is  
wrong because we should distinguish between bad program states and  
argument passing. Moreover the type system doesn't capture the kinds  
of communication iteratees assume of their enumerators/enumeratees,  
nor the kinds of communication supported by the enumerators/ 
enumeratees, which means that failure to hook them up in the right  
(non-typechecked) way /does/ constitute an error.


The one example that tends to be supported is the iteratee  
requesting that the enumerator/enumeratees seek to a given position  
in a file. Which is a good example, but it's not the only one.  
Requesting the resending of chunks is another good example. But  
there's no limit to the reasonable kinds of communication an  
iteratee could want.


In an ideal framework the producers, transformers, and consumers of  
stream data would have a type parameter indicating the up-stream  
communication they support or require (in addition to the type  
parameters for stream type, result type, and side-effect type). That  
way clients can just define an ADT for their communication protocol,  
and be done with it. There may still be issues with the Expression  
Problem, but at least those are pushed out of the stream processing  
framework itself which really shouldn't care about the types of  
communication used.


It's somewhat outdated and underdeveloped (I was writing for myself so  
I never really bothered finishing it), but I wrote an exploration of  
iteratee semantics[1] a while back in which I specified an iteratee as  
a monad-transformer stack involving, at its core, the "PromptT" or  
"ProgramT" monad transformers (as far as I know, the same could be  
done with the "Coroutine" monad).  I personally found that  
construction far more lucid than the usual ad-hoc view, and it also  
makes it very clear how the model can be trivially extended to support  
additional operations such as these.


Based on what I learned while writing that (and on the similarity  
between coroutines and the concepts I used), I strongly agree with  
Mario Blažević, suggestion to look at his monad-coroutine library as  
a way of understanding where they fit in some larger design space.  I  
would even go so far as to suggest that something like it could be  
considered as either a replacement for iteratees or as the underlying  
implementation of an iteratee library, because the concept not only  
subsumes iteratees and enumerators, but also delegates control to code  
that can be independent of both rather than simply reversing the  
"conventional" iterator concept.  I believe it also subsumes iterators  
and whatever their corresponding parts are called.


As he mentions, his implementation does not come with all the  
"plumbing", but I think it would be worthwhile to create that  
plumbing, because either coroutines or "operational monads" may very  
well be the basis needed to develop a "grand unified theory" of  
composable stream processing.  If nothing else, the isomorphisms in  
his coroutine-enumerator[2] and coroutine-iteratee[3] packages seem to  
give a much more direct and useful iteratee semantics than I've seen  
given anywhere else, and at the same time they are much more readily  
extended to cover additional operations.


-- James

1. https://github.com/mokus0/junkbox/tree/master/Papers/HighLevelIteratees
2. http://hackage.haskell.org/package/coroutine-enumerator
3. http://hackage.haskell.org/package/coroutine-iteratee
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[James Cook]

On Mar 28, 2011, at 12:05 PM, Christopher Done wrote:

On 28 March 2011 17:55, malcolm.wallace   
wrote:
Does anyone else think it odd that Prelude.words will break a string  
at a non-breaking space?


Prelude> words "abc def\xA0ghi"
["abc","def","ghi"]

I think it's predictable, isSpace (which words is based on) is based  
on generalCategory, which returns the proper Unicode category:


λ> generalCategory '\xa0'
Space


I agree, and I also agree that it would make sense the other way (not  
breaking on non-breaking spaces).  Perhaps it would be a good idea to  
add a remark to the documentation which specifies the treatment of non- 
breaking spaces.


-- James___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[malcolm.wallace]

I think it's predictable, isSpace (which words is based on) is based on generalCategory, which returns the proper Unicode category:λ> generalCategory '\xa0' SpaceI agree, and I also agree that it would make sense the other way (not breaking on non-breaking spaces).  Perhaps it would be a good idea to add a remark to the documentation which specifies the treatment of non-breaking spaces. I note that Java has two distinct properties concerning whitespace:Character.isSpaceChar('\xA0')  == TrueCharacter.isWhitespace('\xA0') == FalseContrast with -- \x20 is ASCII spaceCharacter.isSpaceChar('\x20')  == TrueCharacter.isWhitespace('\x20') == True -- \x2060 is the word-joiner (zero-width non-breaking space)Character.isSpaceChar('\x2060')  == False Character.isWhitespace('\x2060') == False -- \x202F is the narrow non-breaking spaceCharacter.isSpaceChar('\x202F')  == TrueCharacter.isWhitespace('\x202F') == False  -- \x2009 is the thin spaceCharacter.isSpaceChar('\x2009')  == TrueCharacter.isWhitespace('\x2009') == True___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[Nick Bowler]

On 2011-03-28 16:20 +, malcolm.wallace wrote:
> But what about the author?  Surely there is no reason to use a
> non-breaking space unless they intend it to mean that the characters
> before and after it belong to the same logical unit-of-comprehension?

The "non-breaking" part of non-breaking space refers to breaking text
into lines.  In other words, if two words are separated by a
non-breaking space, then a line break will not be put between those
words.  A non-breaking space does *not* make two words into one word.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[John A. De Goes]

Now THAT"s what I'm talking about. Augment such a solution with interruptible & 
resumable data producers, and I'd have everything I need.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Mar 27, 2011, at 10:54 PM, wren ng thornton wrote:

> In an ideal framework the producers, transformers, and consumers of stream 
> data would have a type parameter indicating the up-stream communication they 
> support or require (in addition to the type parameters for stream type, 
> result type, and side-effect type). That way clients can just define an ADT 
> for their communication protocol, and be done with it. There may still be 
> issues with the Expression Problem, but at least those are pushed out of the 
> stream processing framework itself which really shouldn't care about the 
> types of communication used.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Dynamically linked executables

[Anakim Border]

Hi,

I'm trying to understand if it's possible to build dynamically linked
executables under Mac OS X (10.6) with GHC 7.

Looking here:

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport

it seems like the support is already present.

Inside ghc-7.1.20110325 sources (the latest development snapshots as I
write), I find the following:

# Do we support shared libs?
PlatformSupportsSharedLibs = $(if $(filter $(TARGETPLATFORM),\
   i386-unknown-linux x86_64-unknown-linux \
   i386-unknown-freebsd x86_64-unknown-freebsd \
   i386-unknown-openbsd x86_64-unknown-openbsd \
   i386-unknown-mingw32 \
   i386-unknown-solaris2 \
   i386-apple-darwin powerpc-apple-darwin),YES,NO)

which seems to indicate the contrary.

GHC bug tracker, finally, doesn't show any open ticket on the matter.

Anyone has more details about this?


Thanks,

AB

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[John A. De Goes]

This isn't quite what I'm after. I want to pull chunks on demand (i.e. have 
control over both the input and the output). Enumeratees don't allow me to do 
that.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Mar 27, 2011, at 7:58 PM, John Millikin wrote:

> If the receiver can only accept very small chunks, you can put a rechunking 
> stage in between the compression and iteratee:
> 
> ---
> verySmallChunks :: Monad m => Enumeratee ByteString ByteString m b
> verySmallSchunks = sequence (take 10)
> ---
> 
> Resending is slightly more complex -- if the other end can say "resend that 
> last chunk", then it should be easy enough, but "resend the last 2 bytes of 
> that chunk you sent 5 minutes ago" would be much harder. What is your use 
> case?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Iteratee, ghc 6.12/7.0 strange behaviour - epollControl: permission denied (Operation not permitted)

[Michael A Baikov]

I am still playing with lastest iteratee and i think i found something strange.


let's suppose we have a file test.hs like this:

import Data.Iteratee
import Data.Iteratee.IO
import Data.Iteratee.Char

main = fileDriver printLines "/etc/passwd"

It works fine when executed via runhaskell / ghci in ghc 6.12. Compiled version 
in ghc 7
also works, but when i am trying to execute it via runhaskell / ghci i am 
getting this error:

iter.hs: epollControl: permission denied (Operation not permitted)

Any ideas?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bug in Prelude.words?

[Thomas Davie]

On 28 Mar 2011, at 17:20, malcolm.wallace wrote:

>> Consider an HTML page with that "sentence" displayed on it. If you ask the 
>> viewer of the page how many words are in the sentence, then surely you will 
>> get the answer 3?
>  
> 
> But what about the author?  Surely there is no reason to use a non-breaking 
> space unless they intend it to mean that the characters before and after it 
> belong to the same logical unit-of-comprehension?

I'm not sure that a logical unit-of-comprehension is the same as a word though. 
 As an aside – in publishing non-breaking spaces are commonly used for other 
purposes too, for example forcing a word onto a certain line to stop a space 
river appearing in a paragraph.

Bob


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Iteratee, ghc 6.12/7.0 strange behaviour - epollControl: permission denied (Operation not permitted)

[Johan Tibell]

On Mon, Mar 28, 2011 at 7:31 PM, Michael A Baikov  wrote:
>
>
> I am still playing with lastest iteratee and i think i found something 
> strange.
>
>
> let's suppose we have a file test.hs like this:
>
> import Data.Iteratee
> import Data.Iteratee.IO
> import Data.Iteratee.Char
>
> main = fileDriver printLines "/etc/passwd"
>
> It works fine when executed via runhaskell / ghci in ghc 6.12. Compiled 
> version in ghc 7
> also works, but when i am trying to execute it via runhaskell / ghci i am 
> getting this error:
>
> iter.hs: epollControl: permission denied (Operation not permitted)
>
> Any ideas?

Make sure you have at least GHC 7.0.2. There were some I/O manager
bugs in 7.0.1.

Johan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Saving changes to cabal config in cabal-dev

[Rogan Creswick]

On Sat, Mar 26, 2011 at 2:28 PM, Yitzchak Gale  wrote:
> Thanks for the fantastic cabal-dev tool!

You're welcome!

> Is there any convenient way to save changes to the
> package-specific cabal config file in cabal-dev?

> The only solution I have found so far is to run
> cabal-dev install once (ignoring the errors) to create
> the cabal-dev directory and cabal.config, make a
> copy of cabal.config with a different name, edit it
> as needed, and then use a long-winded
> "--config=..." option for every subsequent run
> cabal-dev.

That is currently the only way to do this :(.  One workaround is to
create an alias for cabal-dev that adds that flag.  e.g., in Bash:

alias cabal-dev = 'cabal-dev --config=cabal.config '

Then you can have a cabal.config next to your project cabal file and
it will use that.  To bypass the alias, just prefix it with "\", e.g.:

$ \cabal-dev

We're working on the first problem -- it's just a matter of finding
the time.  Unfortunately, that's probably not going to happen for
another week or two.  The ticket is here:

https://github.com/creswick/cabal-dev/issues#issue/15

--Rogan
>
> The changes I need to make are as follows:
>
> - remote-repo-cache is wrong for Mac OS X
> - add more remote-repo lines for our local
>  yackage servers.
>
> Note that the first is global, so it would be nice
> to have a way to make that change once globally
> for all packages. Whereas the second is, in
> general, package specific.
>
> We find local yackage servers much simpler to use
> and far more powerful than using add-source.
> You can organize packages by project, team,
> specific developers, etc.
>
> Thanks,
> Yitz
>
> ___
> 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] HsOpenSSL package fails to install

[Rob Nikander]

Hi all,

I tried `cabal install HsOpenSSL` and it died with some errors about
'i2d_of_void'.   I'm on Mac OS X, gcc 4.2.  The symbol 'i2d_of_void'
is defined by a macro in the openssl/asn1.h header, which is
indirectly included, so I don't see the problem.   Any ideas?

If this is a bug, is there a standard way to report it?   Email the
package maintainer in this case?

thanks,
Rob


cbits/HsOpenSSL.c: In function ‘HsOpenSSL_DSAPublicKey_dup’:

cbits/HsOpenSSL.c:220:0:
 error: ‘i2d_of_void’ undeclared (first use in this function)

cbits/HsOpenSSL.c:220:0:
 error: (Each undeclared identifier is reported only once

[... cascading errors from there ...]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] CURL and upload a file

[Evgeny Dzhurinsky]

I found the solution - the header "expect" is not processed by the
server well, so I have had to explicitly set it to empty value - and
then it worked!

-- 
regards
Eugene Dzhurinsky

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] working off a Yesod example file, need help lifting values from one monad into another. (and probably other things too).

[Michael Litchard]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368



I'm working off of a example file from Yesod, ajax.lhs
I've made an important change in types, and this has resulted in
having to make the old code conform to the change. I will point out
the specifics, then present my question. In the event I failed to
include important information, I will paste in my code as well as the
prototype.

[Original]

> getHomeR :: Handler ()
> getHomeR = do
>   Ajax pages _ <- getYesod
>   let first = head pages
>   redirect RedirectTemporary $ PageR $ pageSlug first

[Changed]

> getHomeR :: Handler ()
> getHomeR = do
>   Tframe pages _ <- getYesod
>   let first = head pages
>   redirect RedirectTemporary $ PageR $ pageSlug first

Error Message

test.lhs:62:4:
Constructor `Tframe' should have 2 arguments, but has been given 1
In the pattern: Tframe pages
In a stmt of a 'do' expression: Tframe pages <- getYesod   
This is not what I wrote *
In the expression:
do { Tframe pages <- getYesod;
 content <- widgetToPageContent widget;
 hamletToRepHtml
   (hamlet-0.7.1:Text.Hamlet.Quasi.toHamletValue
  (do { (hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
   . preEscapedString)
  "";
(hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
   . Text.Blaze.toHtml)
  (Main.pageTitle content);
 })) }

As far as I can tell, I only made a cosmetic change. I don't know
what's going on here.



[Original]

> data Page = Page
>   { pageName :: String
>   , pageSlug :: String
>   , pageContent :: String  I'm going to change this **
>   }

[Changed]

> data Page = Page
>   { pageTitle :: String
>   , pageSlug :: String -- ^ used in the URL
>   , pageContent :: IO String    This is the change ***
>   }


Here's where I run into trouble

[Original]
>   json page = jsonMap
>   [ ("name", jsonScalar $ pageName page)
>   , ("content", jsonScalar $ pageContent page)    I'm going to 
> change this 
>   ]



[My changes]

>   json page = jsonMap
>   [ ("name", jsonScalar $ Main.pageTitle page)
>   , ("content", jsonScalar $ liftIO $ pageContent page) *** This is 
> the change ***
>   ]


Here's the compiler error

test.lhs:107:35:
Couldn't match expected type `Char' against inferred type `[Char]'
  Expected type: String
  Inferred type: [String]
In the second argument of `($)', namely `liftIO $ pageContent page'
In the expression: jsonScalar $ liftIO $ pageContent page
Failed, modules loaded: none.


I'd appreciate a discussion about why this is wrong, and perhaps clues
as to what is right.


Last problem, stemming from the change in type to IO String. I don't
have a clue as to what change I should make.

test.lhs:100:25:
No instance for (Text.Blaze.ToHtml (IO String))
  arising from a use of `Text.Blaze.toHtml'
   at test.lhs:(100,25)-(103,3)
Possible fix:
  add an instance declaration for (Text.Blaze.ToHtml (IO String))
In the second argument of `(.)', namely `Text.Blaze.toHtml'
In a stmt of a 'do' expression:
(hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
   . Text.Blaze.toHtml)
  (pageContent page)
In the first argument of
`hamlet-0.7.1:Text.Hamlet.Quasi.toHamletValue', nam

  ely
`do { (hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
 . preEscapedString)
"";
  (hamlet-0.7

Re: [Haskell-cafe] working off a Yesod example file, need help lifting values from one monad into another. (and probably other things too).

[Luke Palmer]

On Mon, Mar 28, 2011 at 6:28 PM, Michael Litchard wrote:

> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 11
> 12
> 13
> 14
> 15
> 16
> 17
> 18
> 19
> 20
> 21
> 22
> 23
> 24
> 25
> 26
> 27
> 28
> 29
> 30
> 31
> 32
> 33
> 34
> 35
> 36
> 37
> 38
> 39
> 40
> 41
> 42
> 43
> 44
> 45
> 46
> 47
> 48
> 49
> 50
> 51
> 52
> 53
> 54
> 55
> 56
> 57
> 58
> 59
> 60
> 61
> 62
> 63
> 64
> 65
> 66
> 67
> 68
> 69
> 70
> 71
> 72
> 73
> 74
> 75
> 76
> 77
> 78
> 79
> 80
> 81
> 82
> 83
> 84
> 85
> 86
> 87
> 88
> 89
> 90
> 91
> 92
> 93
> 94
> 95
> 96
> 97
> 98
> 99
> 100
> 101
> 102
> 103
> 104
> 105
> 106
> 107
> 108
> 109
> 110
> 111
> 112
> 113
> 114
> 115
> 116
> 117
> 118
> 119
> 120
> 121
> 122
> 123
> 124
> 125
> 126
> 127
> 128
> 129
> 130
> 131
> 132
> 133
> 134
> 135
> 136
> 137
> 138
> 139
> 140
> 141
> 142
> 143
> 144
> 145
> 146
> 147
> 148
> 149
> 150
> 151
> 152
> 153
> 154
> 155
> 156
> 157
> 158
> 159
> 160
> 161
> 162
> 163
> 164
> 165
> 166
> 167
> 168
> 169
> 170
> 171
> 172
> 173
> 174
> 175
> 176
> 177
> 178
> 179
> 180
> 181
> 182
> 183
> 184
> 185
> 186
> 187
> 188
> 189
> 190
> 191
> 192
> 193
> 194
> 195
> 196
> 197
> 198
> 199
> 200
> 201
> 202
> 203
> 204
> 205
> 206
> 207
> 208
> 209
> 210
> 211
> 212
> 213
> 214
> 215
> 216
> 217
> 218
> 219
> 220
> 221
> 222
> 223
> 224
> 225
> 226
> 227
> 228
> 229
> 230
> 231
> 232
> 233
> 234
> 235
> 236
> 237
> 238
> 239
> 240
> 241
> 242
> 243
> 244
> 245
> 246
> 247
> 248
> 249
> 250
> 251
> 252
> 253
> 254
> 255
> 256
> 257
> 258
> 259
> 260
> 261
> 262
> 263
> 264
> 265
> 266
> 267
> 268
> 269
> 270
> 271
> 272
> 273
> 274
> 275
> 276
> 277
> 278
> 279
> 280
> 281
> 282
> 283
> 284
> 285
> 286
> 287
> 288
> 289
> 290
> 291
> 292
> 293
> 294
> 295
> 296
> 297
> 298
> 299
> 300
> 301
> 302
> 303
> 304
> 305
> 306
> 307
> 308
> 309
> 310
> 311
> 312
> 313
> 314
> 315
> 316
> 317
> 318
> 319
> 320
> 321
> 322
> 323
> 324
> 325
> 326
> 327
> 328
> 329
> 330
> 331
> 332
> 333
> 334
> 335
> 336
> 337
> 338
> 339
> 340
> 341
> 342
> 343
> 344
> 345
> 346
> 347
> 348
> 349
> 350
> 351
> 352
> 353
> 354
> 355
> 356
> 357
> 358
> 359
> 360
> 361
> 362
> 363
> 364
> 365
> 366
> 367
> 368
>

Ready or not, here I come.

What is the purposes of these 368 numbers?

Luke



>
>
>
> I'm working off of a example file from Yesod, ajax.lhs
> I've made an important change in types, and this has resulted in
> having to make the old code conform to the change. I will point out
> the specifics, then present my question. In the event I failed to
> include important information, I will paste in my code as well as the
> prototype.
>
> [Original]
>
> > getHomeR :: Handler ()
> > getHomeR = do
> >   Ajax pages _ <- getYesod
> >   let first = head pages
> >   redirect RedirectTemporary $ PageR $ pageSlug first
>
> [Changed]
>
> > getHomeR :: Handler ()
> > getHomeR = do
> >   Tframe pages _ <- getYesod
> >   let first = head pages
> >   redirect RedirectTemporary $ PageR $ pageSlug first
>
> Error Message
>
> test.lhs:62:4:
>Constructor `Tframe' should have 2 arguments, but has been given 1
>In the pattern: Tframe pages
>In a stmt of a 'do' expression: Tframe pages <- getYesod   
> This is not what I wrote *
>In the expression:
>do { Tframe pages <- getYesod;
> content <- widgetToPageContent widget;
> hamletToRepHtml
>   (hamlet-0.7.1:Text.Hamlet.Quasi.toHamletValue
>  (do { (hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
>   . preEscapedString)
>  "";
>(hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
>   . Text.Blaze.toHtml)
>  (Main.pageTitle content);
> })) }
>
> As far as I can tell, I only made a cosmetic change. I don't know
> what's going on here.
>
>
>
> [Original]
>
> > data Page = Page
> >   { pageName :: String
> >   , pageSlug :: String
> >   , pageContent :: String  I'm going to change this
> **
> >   }
>
> [Changed]
>
> > data Page = Page
> >   { pageTitle :: String
> >   , pageSlug :: String -- ^ used in the URL
> >   , pageContent :: IO String    This is the change
> ***
> >   }
>
>
> Here's where I run into trouble
>
> [Original]
> >   json page = jsonMap
> >   [ ("name", jsonScalar $ pageName page)
> >   , ("content", jsonScalar $ pageContent page)    I'm going
> to change this 
> >   ]
>
>
>
> [My changes]
>
> >   json page = jsonMap
> >   [ ("name", jsonScalar $ Main.pageTitle page)
> >   , ("content", jsonScalar $ liftIO $ pageContent page) *** This
> is the change ***
> >   ]
>
>
> Here's the compiler error
>
> test.lhs:107:35:
>Couldn't match expected type `Char' against inferred type `[Char]'
>  Expected type: String
>  Inferred type: [String]
>In the second argument of `($)', namely `liftIO $ pageContent page'
>In the e

Re: [Haskell-cafe] working off a Yesod example file, need help lifting values from one monad into another. (and probably other things too).

[Michael Litchard]

I just noticed those. I think that came from hpaste. The first mail
was a cut and paste from a post I made there. When I went to look at
your reply, I had the very same question as you.

On Mon, Mar 28, 2011 at 7:51 PM, Luke Palmer  wrote:
> On Mon, Mar 28, 2011 at 6:28 PM, Michael Litchard 
> wrote:
>>
>> 1
>> 2
>> 3
>> 4
>> 5
>> 6
>> 7
>> 8
>> 9
>> 10
>> 11
>> 12
>> 13
>> 14
>> 15
>> 16
>> 17
>> 18
>> 19
>> 20
>> 21
>> 22
>> 23
>> 24
>> 25
>> 26
>> 27
>> 28
>> 29
>> 30
>> 31
>> 32
>> 33
>> 34
>> 35
>> 36
>> 37
>> 38
>> 39
>> 40
>> 41
>> 42
>> 43
>> 44
>> 45
>> 46
>> 47
>> 48
>> 49
>> 50
>> 51
>> 52
>> 53
>> 54
>> 55
>> 56
>> 57
>> 58
>> 59
>> 60
>> 61
>> 62
>> 63
>> 64
>> 65
>> 66
>> 67
>> 68
>> 69
>> 70
>> 71
>> 72
>> 73
>> 74
>> 75
>> 76
>> 77
>> 78
>> 79
>> 80
>> 81
>> 82
>> 83
>> 84
>> 85
>> 86
>> 87
>> 88
>> 89
>> 90
>> 91
>> 92
>> 93
>> 94
>> 95
>> 96
>> 97
>> 98
>> 99
>> 100
>> 101
>> 102
>> 103
>> 104
>> 105
>> 106
>> 107
>> 108
>> 109
>> 110
>> 111
>> 112
>> 113
>> 114
>> 115
>> 116
>> 117
>> 118
>> 119
>> 120
>> 121
>> 122
>> 123
>> 124
>> 125
>> 126
>> 127
>> 128
>> 129
>> 130
>> 131
>> 132
>> 133
>> 134
>> 135
>> 136
>> 137
>> 138
>> 139
>> 140
>> 141
>> 142
>> 143
>> 144
>> 145
>> 146
>> 147
>> 148
>> 149
>> 150
>> 151
>> 152
>> 153
>> 154
>> 155
>> 156
>> 157
>> 158
>> 159
>> 160
>> 161
>> 162
>> 163
>> 164
>> 165
>> 166
>> 167
>> 168
>> 169
>> 170
>> 171
>> 172
>> 173
>> 174
>> 175
>> 176
>> 177
>> 178
>> 179
>> 180
>> 181
>> 182
>> 183
>> 184
>> 185
>> 186
>> 187
>> 188
>> 189
>> 190
>> 191
>> 192
>> 193
>> 194
>> 195
>> 196
>> 197
>> 198
>> 199
>> 200
>> 201
>> 202
>> 203
>> 204
>> 205
>> 206
>> 207
>> 208
>> 209
>> 210
>> 211
>> 212
>> 213
>> 214
>> 215
>> 216
>> 217
>> 218
>> 219
>> 220
>> 221
>> 222
>> 223
>> 224
>> 225
>> 226
>> 227
>> 228
>> 229
>> 230
>> 231
>> 232
>> 233
>> 234
>> 235
>> 236
>> 237
>> 238
>> 239
>> 240
>> 241
>> 242
>> 243
>> 244
>> 245
>> 246
>> 247
>> 248
>> 249
>> 250
>> 251
>> 252
>> 253
>> 254
>> 255
>> 256
>> 257
>> 258
>> 259
>> 260
>> 261
>> 262
>> 263
>> 264
>> 265
>> 266
>> 267
>> 268
>> 269
>> 270
>> 271
>> 272
>> 273
>> 274
>> 275
>> 276
>> 277
>> 278
>> 279
>> 280
>> 281
>> 282
>> 283
>> 284
>> 285
>> 286
>> 287
>> 288
>> 289
>> 290
>> 291
>> 292
>> 293
>> 294
>> 295
>> 296
>> 297
>> 298
>> 299
>> 300
>> 301
>> 302
>> 303
>> 304
>> 305
>> 306
>> 307
>> 308
>> 309
>> 310
>> 311
>> 312
>> 313
>> 314
>> 315
>> 316
>> 317
>> 318
>> 319
>> 320
>> 321
>> 322
>> 323
>> 324
>> 325
>> 326
>> 327
>> 328
>> 329
>> 330
>> 331
>> 332
>> 333
>> 334
>> 335
>> 336
>> 337
>> 338
>> 339
>> 340
>> 341
>> 342
>> 343
>> 344
>> 345
>> 346
>> 347
>> 348
>> 349
>> 350
>> 351
>> 352
>> 353
>> 354
>> 355
>> 356
>> 357
>> 358
>> 359
>> 360
>> 361
>> 362
>> 363
>> 364
>> 365
>> 366
>> 367
>> 368
>
> Ready or not, here I come.
> What is the purposes of these 368 numbers?
> Luke
>
>>
>>
>> I'm working off of a example file from Yesod, ajax.lhs
>> I've made an important change in types, and this has resulted in
>> having to make the old code conform to the change. I will point out
>> the specifics, then present my question. In the event I failed to
>> include important information, I will paste in my code as well as the
>> prototype.
>>
>> [Original]
>>
>> > getHomeR :: Handler ()
>> > getHomeR = do
>> >   Ajax pages _ <- getYesod
>> >   let first = head pages
>> >   redirect RedirectTemporary $ PageR $ pageSlug first
>>
>> [Changed]
>>
>> > getHomeR :: Handler ()
>> > getHomeR = do
>> >   Tframe pages _ <- getYesod
>> >   let first = head pages
>> >   redirect RedirectTemporary $ PageR $ pageSlug first
>>
>> Error Message
>>
>> test.lhs:62:4:
>>    Constructor `Tframe' should have 2 arguments, but has been given 1
>>    In the pattern: Tframe pages
>>    In a stmt of a 'do' expression: Tframe pages <- getYesod   
>> This is not what I wrote *
>>    In the expression:
>>        do { Tframe pages <- getYesod;
>>             content <- widgetToPageContent widget;
>>             hamletToRepHtml
>>               (hamlet-0.7.1:Text.Hamlet.Quasi.toHamletValue
>>                  (do { (hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
>>                       . preEscapedString)
>>                          "";
>>                        (hamlet-0.7.1:Text.Hamlet.Quasi.htmlToHamletMonad
>>                       . Text.Blaze.toHtml)
>>                          (Main.pageTitle content);
>>                         })) }
>>
>> As far as I can tell, I only made a cosmetic change. I don't know
>> what's going on here.
>>
>>
>>
>> [Original]
>>
>> > data Page = Page
>> >   { pageName :: String
>> >   , pageSlug :: String
>> >   , pageContent :: String      I'm going to change this
>> > **
>> >   }
>>
>> [Changed]
>>
>> > data Page = Page
>> >       { pageTitle :: String
>> >       , pageSlug :: String -- ^ used in the URL
>> >       , pageContent :: IO String            This is the change
>> > ***
>> >       }
>>
>>
>> Here's where I run into trouble
>>
>> [

[Haskell-cafe] How to best deal with nullPtr from alloca and friends?

[Jason Dagit]

I was reading up on the documentation for alloca and friends[1], which says,
"If any of the allocation functions fails, a value of
nullPtr
is
produced."

It seems like every example of FFI code that I find which uses alloca
ignores the possibility of a nullPtr[2, 3, 4].

So then I started trying out examples with the help of dmwit and others from
#haskell.

It seems that actually, alloca and friends throw exceptions:
dmwit> main = allocaArray (2^30) (\ptr -> print ((nullPtr :: Ptr Double) ==
ptr))
 lispy: alloca also throws an exception.
 lispy: Or rather, allocaBytes throws an exception, and alloca is
implemented in terms of allocaBytes, so I'm *guessing* that alloca throws an
exception.

I'm on a 64bit version of windows here with more than 4GB of memory to spare
for the GHC process. Unfortunately, allocaBytes takes an Int so I can't test
it with a request larger than the amount of physical ram I have.

Just playing around with different arguments to allocaBytes I can get
different behavior:
 <= 2^30 bytes, works perfectly
 == 2^30 + 2^20 bytes, I get an ": out of memory" message and
ghci terminates
 == 2^31-1, I get a crash where windows pops up a little dialog saying my
program (ghci) has crashed.

The behavior seems to be inconsistent with the documentation.

What is the correct behavior for alloca and friends and should I be checking
for nullPtr?

Thanks,
Jason


[1]
http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-Marshal-Alloc.html
[2] http://en.wikibooks.org/wiki/Haskell/FFI
[3] http://www.haskell.org/haskellwiki/HSFFIG/Examples
[4] http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to best deal with nullPtr from alloca and friends?

[Jason Dagit]

On Mon, Mar 28, 2011 at 9:43 PM, Jason Dagit  wrote:

>

I'm on a 64bit version of windows here with more than 4GB of memory to spare
> for the GHC process. Unfortunately, allocaBytes takes an Int so I can't test
> it with a request larger than the amount of physical ram I have.
>

It would seem that the Haskell Platform for windows only ships a 32 bit
binary.  That is rather unfortunate:
$ ghci +RTS --info
WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in
partic
ular)
 doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper
instead
 [("GHC RTS", "YES")
 ,("GHC version", "7.0.2")
 ,("RTS way", "rts_thr")
 ,("Build platform", "i386-unknown-mingw32")
 ,("Build architecture", "i386")
 ,("Build OS", "mingw32")
 ,("Build vendor", "unknown")
 ,("Host platform", "i386-unknown-mingw32")
 ,("Host architecture", "i386")
 ,("Host OS", "mingw32")
 ,("Host vendor", "unknown")
 ,("Target platform", "i386-unknown-mingw32")
 ,("Target architecture", "i386")
 ,("Target OS", "mingw32")
 ,("Target vendor", "unknown")
 ,("Word size", "32")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ]

With a 64bit build, perhaps I could experiment more.  I looked at the
Haskell Platform page and I don't see a 64bit version.  It would seem the
binary from GHC HQ has the same limitation since there is only one installer
and it claims to work on windows 2000:
http://www.haskell.org/ghc/download_ghc_7_0_3#windows

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] object oriented technique

[Tad Doxsee]

I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection.
It took me a while, but I found a solution that meets
my needs. It's a combination of solutions that I saw on the
web, but I've never seen it presented in a way that combines both
in a short note. (I'm sure it's out there somewhere, but it's off the beaten
path that I've been struggling along.)  The related solutions
are

1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf

2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections

I'm looking for comments on the practicality of the solution,
and references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.

Using the standard example, here's the code:


data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)

drawRect :: Rectangle -> String
drawRect r = "Rect (" ++ show (rx r) ++ ", "  ++ show (ry r) ++ ") -- "
 ++ show (rw r) ++ " x " ++ show (rh r)


data Circle = Circle {cx, cy, cr :: Double}
deriving (Eq, Show)

drawCirc :: Circle -> String
drawCirc c = "Circ (" ++ show (cx c) ++ ", " ++ show (cy c)++ ") -- "
 ++ show (cr c)

r1 = Rectangle 0 0 3 2
r2 = Rectangle 1 1 4 5
c1 = Circle 0 0 5
c2 = Circle 2 0 7


rs = [r1, r2]
cs = [c1, c2]

rDrawing = map drawRect rs
cDrawing = map drawCirc cs

-- shapes = rs ++ cs

Of course, the last line won't compile because the standard Haskell list
may contain only homogeneous types.  What I wanted to do is create a list of
circles and rectangles, put them in a list, and draw them.  It was easy
for me to find on the web and in books how to do that if I controlled
all of the code. What wasn't immediately obvious to me was how to do that
in a library that could be extended by others.  The references noted
previously suggest this solution:


class ShapeC s where
  draw :: s -> String
  copyTo :: s -> Double -> Double -> s

-- needs {-# LANGUAGE GADTs #-}
data ShapeD  where
  ShapeD :: ShapeC s => s -> ShapeD

instance ShapeC ShapeD where
  draw (ShapeD s) = draw s
  copyTo (ShapeD s) x y = ShapeD (copyTo s x y)

mkShape :: ShapeC s => s -> ShapeD
mkShape s = ShapeD s



instance ShapeC Rectangle where
  draw = drawRect
  copyTo (Rectangle _ _ rw rh) x y = Rectangle x y rw rh

instance ShapeC Circle where
  draw = drawCirc
  copyTo (Circle _ _ r) x y = Circle x y r


r1s = ShapeD r1
r2s = ShapeD r2
c1s = ShapeD c1
c2s = ShapeD c2

shapes1 = [r1s, r2s, c1s, c2s]
drawing1 = map draw shapes1

shapes2 = map mkShape rs ++ map mkShape cs
drawing2 = map draw shapes2

-- copy the shapes to the origin then draw them
shapes3 = map (\s -> copyTo s 0 0) shapes2
drawing3 = map draw shapes3


Another user could create a list of shapes that included triangles by creating
a ShapeC instance for his triangle and using mkShape to add it to a list of
ShapeDs.

Is the above the standard method in Haskell for creating an extensible
heterogeneous list of "objects" that share a common interface?  Are there better
approaches?  (I ran into a possible limitation to this approach that I plan
to ask about later if I can't figure it out myself.)

- Tad

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[John Millikin]

Since the release, a couple people have sent in feature requests, so I'm 
going to put out 0.4.9 in a day or so.

New features will be:

- tryIO: runs an IO computation, and converts any exceptions into 
``throwError`` calls (requested by Kazu Yamamoto)

- checkContinue: encapsulates a common pattern (loop (Continue k) = ...) 
when defining enumerators

- mapAccum and mapAccum: sort of like map and mapM, except the step function 
is stateful (requested by Long Huynh Huu)

Anyone else out there sitting on a request? Please send them in -- I am 
always happy to receive them, even if they must be declined.

---

Also, I would like to do a quick poll regarding operators.

1. It has been requested that I add operator aliases for joinI and joinE.

2. There have been complaints that the library defines too many operators 
(currently, 5).

Do any existing enumerator users, or anyone for that matter, have an opinion 
either way?

The proposed operators are:

--
infixr 0 =$
infixr 0 $=

(=$) :: Monad m => Enumeratee ao ai m b -> Iteratee ai m b -> Iteratee ao m 
b
enum =$ iter = joinI (enum $$ iter)

($=) :: Monad m => Enumerator ao m (Step ai m b) -> Enumeratee ao ai m b -> 
Enumerator ai m b
($=) = joinE
--

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[Michael Snoyman]

On Tue, Mar 29, 2011 at 7:50 AM, John Millikin  wrote:
> Since the release, a couple people have sent in feature requests, so I'm
> going to put out 0.4.9 in a day or so.
>
> New features will be:
>
> - tryIO: runs an IO computation, and converts any exceptions into
> ``throwError`` calls (requested by Kazu Yamamoto)
>
> - checkContinue: encapsulates a common pattern (loop (Continue k) = ...)
> when defining enumerators
>
> - mapAccum and mapAccum: sort of like map and mapM, except the step function
> is stateful (requested by Long Huynh Huu)
>
> Anyone else out there sitting on a request? Please send them in -- I am
> always happy to receive them, even if they must be declined.
>
> ---
>
> Also, I would like to do a quick poll regarding operators.
>
> 1. It has been requested that I add operator aliases for joinI and joinE.
>
> 2. There have been complaints that the library defines too many operators
> (currently, 5).
>
> Do any existing enumerator users, or anyone for that matter, have an opinion
> either way?
>
> The proposed operators are:
>
> --
> infixr 0 =$
> infixr 0 $=
>
> (=$) :: Monad m => Enumeratee ao ai m b -> Iteratee ai m b -> Iteratee ao m
> b
> enum =$ iter = joinI (enum $$ iter)
>
> ($=) :: Monad m => Enumerator ao m (Step ai m b) -> Enumeratee ao ai m b ->
> Enumerator ai m b
> ($=) = joinE
> --

The operators sound good to me. My only request would be to put in a
usage example in the documentation. I'd be happy to write one if you'd
like. Personally, I think that =$ will *greatly* clean up my code.

Michael

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Iteratee, ghc 6.12/7.0 strange behaviour -epollControl: permission denied (Operation not permitted)

[Michael A Baikov]

I tried with both 7.0.2 and 7.0.3

-Original Message-

> On Mon, Mar 28, 2011 at 7:31 PM, Michael A Baikov  wrote:
> >
> >
> > I am still playing with lastest iteratee and i think i found something 
> > strange.
> >
> >
> > let's suppose we have a file test.hs like this:
> >
> > import Data.Iteratee
> > import Data.Iteratee.IO
> > import Data.Iteratee.Char
> >
> > main = fileDriver printLines "/etc/passwd"
> >
> > It works fine when executed via runhaskell / ghci in ghc 6.12. Compiled 
> > version in ghc 7
> > also works, but when i am trying to execute it via runhaskell / ghci i am 
> > getting this error:
> >
> > iter.hs: epollControl: permission denied (Operation not permitted)
> >
> > Any ideas?
> 
> Make sure you have at least GHC 7.0.2. There were some I/O manager
> bugs in 7.0.1.
> 
> Johan
> 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe