ihope | 1 Aug 01:15 2006
Picon

Non-drifting clock, anyone?

Here it is, in all its greatly untested glory: http://pastebin.ca/109242

I don't know how much error it has, but the error won't stack up: if
it's one second off, it will remain one second off until the end of
time, or until your system clock drifts. But system clock drifts will
be fixed by synchronizing your system clock with the outside world,
except that if your clock jumps forward, this one will suddenly tick
like mad, and if it jumps backward, this one will stop for a while...
oh well.
Lemmih | 1 Aug 09:15 2006
Picon

AngloHaskell: Call for Participation

Greetings fellow hackers,

It is my great pleasure to call attention to the informal gathering of
the Haskell community. The event will take place at Cambridge, UK, on
Friday and Saturday the 4-5th of August. Don't miss this opportunity
to:
 * associate IRC handles with faces,
 * drink beer,
 * ride unicycles and
 * much more.

The event is of course free and non-haskellers are welcome as well.
More information can be found here: http://haskell.org/haskellwiki/AngloHaskell

--

-- 
Friendly,
  Lemmih
Einar Karttunen | 1 Aug 11:44 2006
Picon
Picon

Re: thread-local variables

On 31.07 23:53, Adrian Hey wrote:
> Frederik Eaton wrote:
> >On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote:
> >>On 31.07 03:18, Frederik Eaton wrote:
> >>4) the library runs the callback code in Tw where the TLS state is
> >>   invalid. This is even worse than a global variable in this case.
> >
> >If you have threads, and you have something which needs to be
> >different among different threads, then it is hard for me to see how
> >thread-local variables could be worse than global variables in any
> >case at all.
> 
> I haven't been following the technicalities of the particular
> scenario that's under discussion so I don't know exactly
> what either of you mean by "(even) worse than global variables".
> 
> I just want to point out that, as I (and a few others) see it at
> least, top level mutable state (aka "global variables") is
> absolutely necessary sometimes for _SAFETY_ reasons.

I agree that global variables are sometimes the best solution.
My point in the quote was that in the example described
TLS would cause more trouble than global mutable state.

> But I would say that I think I would find having to know what thread
> a particular bit of code was running in in order to "grok it" very
> strange, unless there was some obvious technical reason why the
> thread local state needed to be thread local (can't think of any
> such reason right now).

(Continue reading)

Simon Peyton-Jones | 1 Aug 18:32 2006
Picon

RE: Internships on GHC and Haskell at MSR Cambridge

| MSR Cambridge now takes interns *year-round*, not just in the summer
months.  Simon Marlow and I
| are keen to attract motivated and well-qualified folk to work with us
on our research, and on improving
| or developing GHC.

PS: concerning the enclosed, if you are interested in an internship at
MSR for the October-December 2006 period, you'll need to get weaving
very quickly.  Because of summer holidays etc, we'll be taking decisions
in the week of 14 August, so you'll need to get your application
(including references) in by 13 August.

Simon

| -----Original Message-----
| From: Simon Peyton-Jones
| Sent: 25 July 2006 10:56
| To: haskell-cafe <at> haskell.org; haskell <at> haskell.org;
glasgow-haskell-users <at> haskell.org
| Subject: Internships on GHC and Haskell at MSR Cambridge
| 
| Gentle Haskellers
| 
| Would you be interested in working for three months at Microsoft
Research, Cambridge, on a project
| related to GHC or Haskell?
| 
| MSR Cambridge now takes interns *year-round*, not just in the summer
months.  Simon Marlow and I
| are keen to attract motivated and well-qualified folk to work with us
(Continue reading)

Harald ROTTER | 2 Aug 10:52 2006

Monadic parser combinators with logging


Dear all,

I am a Haskell newbie and I try to find my way through Monad territory.
Actually I am studying the non-deterministic monadic parser combinators as
descibed by Hutton and Meijer. Although I find this very elegant
and concise I seem to have problems extending the parser monads.
I use

newtype Parser a = Parser { runParser :: (PState -> [(a, PState)])}

as the parsing monad with the Parser state  "PState" that contains the
remaining input after matching and possibly some additional user defined
state elements. I want to add logging such that the application of every
element parser/parser combinator gets recorded in a string. In the end I
want to print out the trace of all encountered parsers for successful and
for failed matches.

I tried to use the WriterT transformer to add a writer monad on top of the
Parser monad but for failed matches (i.e. runParser gives []) the log is
also "lost" since WriterT gives a monad of "m (a,w)". What I would look for
is "(m a, w)".

Finally, my questions:
What is the most elegant way to achieve logging parsers ?
Can I use the standard transformes or do I need to write my own
transformers ?
How can I make the Parser monad given above an instance of MonadState ? (I
always get kind errors ...)

(Continue reading)

Harald ROTTER | 2 Aug 10:59 2006

Monadic parser combinators with logging


Dear all,

I am a Haskell newbie and I try to find my way through Monad territory.
Actually I am studying the non-deterministic monadic parser combinators as
descibed by Hutton and Meijer. Although I find this very elegant
and concise I seem to have problems extending the parser monads.
I use

newtype Parser a = Parser { runParser :: (PState -> [(a, PState)])}

as the parsing monad with the Parser state  "PState" that contains the
remaining input after matching and possibly some additional user defined
state elements. I want to add logging such that the application of every
element parser/parser combinator gets recorded in a string. In the end I
want to print out the trace of all encountered parsers for successful and
for failed matches.

I tried to use the WriterT transformer to add a writer monad on top of the
Parser monad but for failed matches (i.e. runParser gives []) the log is
also "lost" since WriterT gives a monad of "m (a,w)". What I would look for
is "(m a, w)".

Finally, my questions:
What is the most elegant way to achieve logging parsers ?
Can I use the standard transformes or do I need to write my own
transformers ?
How can I make the Parser monad given above an instance of MonadState ? (I
always get kind errors ...)

(Continue reading)

Chris Kuklewicz | 2 Aug 13:16 2006

ANN: TextRegexLazy-0.56, (=~) and (=~~) are here

Announcing: TextRegexLazy version 0.56
Where: Tarball from http://sourceforge.net/projects/lazy-regex
        darcs get --partial [--tag=0.56] http://evenmere.org/~chrisk/trl/stable/
License : BSD, except for DFAEngine.hs which is LGPL (derived from CTK light)

Development/unstable version is at:
        darcs get [--partial] http://evenmere.org/~chrisk/trl/devel/

This is the version that has eaten John Meacham's JRegex library and survived to 
become strong.  Thanks John!

It now compiles against the posix regexp provided by the c library and the pcre 
library, in addition to the "full lazy" and the "DFA" backends.

All 4 backends can accept regular expressions given as String and as ByteString.

All 4 backends can run regular expressions against String and ByteString.

In particular, the PosixRE and PCRE can run very efficiently against ByteString. 
(Though the input for the PosixRE needs to end in a \NUL character for efficiency).

So there are 4*2*2 = 16 ways to use to provide input to this library.  And the 
RegexContext class has at least 11 instances that both (=~) and (=~~) can 
target.  So that is 4*2*2*11*2 = 352 things you can do with this library!  Get 
your copy today!

To run with cabal before 1.1.4 you will need to comment out the 
"Extra-Source-Files:" line in the TextRegexLazy.cabal file.

The Example.hs file:
(Continue reading)

Chris Kuklewicz | 2 Aug 13:33 2006

Re: ANN: TextRegexLazy-0.56, (=~) and (=~~) are here

Ooops.

I just patched the efficiency of ByteStringPCRE to agree with the original 
announcement.

Use
darcs get --partial http://evenmere.org/~chrisk/trl/stable/
to get the fixed version.

A new 0.57 tarball will go to sourceforge soon.

Chris Kuklewicz wrote:
> Announcing: TextRegexLazy version 0.56
> Where: Tarball from http://sourceforge.net/projects/lazy-regex
>        darcs get --partial [--tag=0.56] 
> http://evenmere.org/~chrisk/trl/stable/
> License : BSD, except for DFAEngine.hs which is LGPL (derived from CTK 
> light)
> 
> Development/unstable version is at:
>        darcs get [--partial] http://evenmere.org/~chrisk/trl/devel/
> 
> This is the version that has eaten John Meacham's JRegex library and 
> survived to become strong.  Thanks John!
> 
> It now compiles against the posix regexp provided by the c library and 
> the pcre library, in addition to the "full lazy" and the "DFA" backends.
> 
> All 4 backends can accept regular expressions given as String and as 
> ByteString.
(Continue reading)

Brian Hulley | 3 Aug 00:15 2006

Re: ANN: TextRegexLazy-0.56, (=~) and (=~~) are here

Chris Kuklewicz wrote:
> Announcing: TextRegexLazy version 0.56
> Where: Tarball from http://sourceforge.net/projects/lazy-regex
>        darcs get --partial [--tag=0.56]
> http://evenmere.org/~chrisk/trl/stable/ License : BSD, except for

Great! - Thanks for all your hard work in making this available to everyone!

> DFAEngine.hs which is LGPL (derived from CTK light)

I sense some possible problems coming...

[in another post]
>Bulat Ziganshin wrote:
>> Hello Chris,
>>
>> Wednesday, August 2, 2006, 3:16:58 PM, you wrote:
>>
>>> Announcing: TextRegexLazy version 0.56
>>
>> your feature list is really strong! it will be great now to make it
>> a part of GHC standard distribution

Does the LGPL license for DFAEngine.hs use the static linking exception or 
not?

If so, and if it is desirable to allow LGPL code without the static linking 
exception into the standard lib distro, then perhaps a useful project for 
someone would be to write a Haskell program that traverses source for an app 
and builds an appropriate static library containing the object code for all 
(Continue reading)

Chris Kuklewicz | 3 Aug 01:16 2006

Re: [Haskell-cafe] ANN: TextRegexLazy-0.56, (=~) and (=~~) are here

Brian Hulley wrote:
> Chris Kuklewicz wrote:
>> Announcing: TextRegexLazy version 0.56
>> Where: Tarball from http://sourceforge.net/projects/lazy-regex
>>        darcs get --partial http://evenmere.org/~chrisk/trl/stable/
>> License : BSD, except for
> 
> Great! - Thanks for all your hard work in making this available to 
> everyone!
> 
>> DFAEngine.hs which is LGPL (derived from CTK light)
> 
> I sense some possible problems coming...

I wrote that ominous line, so I would have to agree.

> 
> [in another post]
>> Bulat Ziganshin wrote:
>>> Hello Chris,
>>>
>>> Wednesday, August 2, 2006, 3:16:58 PM, you wrote:
>>>
>>>> Announcing: TextRegexLazy version 0.56
>>>
>>> your feature list is really strong! it will be great now to make it
>>> a part of GHC standard distribution
> 
> Does the LGPL license for DFAEngine.hs use the static linking exception 
> or not?
(Continue reading)


Gmane