date:20130121

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

2013-01-21 Thread Alexander Kjeldaas

I think you can test this theory with this patch.  If a thread is waiting
on the task-cond condition variable which is matched up with task-lock,
then pthread_cond_destroy will return EBUSY, which must always be a bug in
the RTS.

Alexander

diff --git a/rts/posix/OSThreads.c b/rts/posix/OSThreads.c
index ae31966..0f12830 100644
--- a/rts/posix/OSThreads.c
+++ b/rts/posix/OSThreads.c
@@ -91,7 +91,8 @@ initCondition( Condition* pCond )
 void
 closeCondition( Condition* pCond )
 {
-  pthread_cond_destroy(pCond);
+  int ret = pthread_cond_destroy(pCond);
+  CHECKM(ret == 0, RTS BUG! Someone is waiting on condvar %d., ret);
   return;
 }



On Mon, Jan 21, 2013 at 8:18 AM, Alexander Kjeldaas 
alexander.kjeld...@gmail.com wrote:


 I just looked at this code and since I don't know the code I can't give
 you good solutions, but for others watching this thread the links might
 prove interesting.

 My main theory is that you do have some other thread in FFI-land while you
 are fork()ing.  The task-cond, task-lock seems to be related to this (see
 quoted comments below).

 Also, pthread_mutex_destroy is undefined if the lock is locked, so I am
 guessing that the task-lock is somehow locked when it shouldn't be.

 It isn't clear from your description whether this is consistently
 happening on Linux, or whether this only sometimes happens.

 The forkProcess() code seems to hold all capabilities during fork, but
 that does not include FFI-land threads AFAIU.

 Assuming that this happens only rarely, I am trying to understand what
 happens if the thread that is in FFI-land returns to the RTS (in the
 parent) after fork(), but before the freeTask() in the child.  Based on the
 descriptions I read, it seems likely that this thread will try to inspect
 task-cap, which requires holding task-lock.

 That would in turn make the pthread_mutex_destroy in the child invalid.

 https://github.com/ghc/ghc/blob/master/rts/Task.h#L57

 
  ...
  When a task is migrated from sleeping on one Capability to another,
its task-cap field must be modified.  When the task wakes up, it
will read the new value of task-cap to find out which Capability
it belongs to.  Hence some synchronisation is required on
task-cap, and this is why we have task-lock.

If the Task is not currently owned by task-id, then the thread is
either

  (a) waiting on the condition task-cond.  The Task is either
  (1) a bound Task, the TSO will be on a queue somewhere
  (2) a worker task, on the spare_workers queue of task-cap.
...
 

 freeTask:
 https://github.com/ghc/ghc/blob/master/rts/Task.c#L142

 the comment in freeTask refers to this test:

 https://github.com/ghc/testsuite/blob/master/tests/concurrent/should_run/conc059.hs

 That test calls the RTC from C which then forkIOs off actions that are
 outstanding when the RTS exits.

 in forkProcess, child code
 https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L1837

 It look like all this code supports the notion that some other thread can
 be in foreign code during the fork call.

 discardTasksExcept
 https://github.com/ghc/ghc/blob/master/rts/Task.c#L305


 Alexander


 On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner mark.lentcz...@gmail.com
  wrote:

 Sorry to be reviving this thread so long after but I seem to be
 running into similar issues as Michael S. did at the start.

 In short, I'm using forkProcess with the threaded RTS, and see occasional
 hangs:

- I see these only on Linux. On Mac OS X, I never do.
- I'm using GHC 7.4.2
- I noticed the warning in the doc for forkProcess, but assumed I was
safe, as I wasn't holding any shared resources at the time of the fork, 
 and
no shared resources in the program are used in the child.
- WIth gdb, I've traced the hang to here in the run-time: forkProcess
 discardTasksExcept  freeTask  closeMutex(task-lock)
 pthread_mutex_destroy

 The discussion in this thread leaves me with these questions:

- Is there reason to think the situation has gotten better in 7.6 and
later?
- Isn't the only reason *System.Process* is safer because it does an
immediate exec in the child? Alas, I really want to just fork()sometimes.
- Is it really true that even if my program has no shared resources
with the child, that the IO subsystem and FFI system do anyway? Surely the
RTS would take care of doing the right thing with those, no?
- There should be no concern with exec w.r.t. library invariants
since exec is wholesale replacement - all the libraries will
reinitialize. Is there a problem here I'm missing?

 Alas, I've stopped using the threaded RTS until I understand this better.

 - Mark



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

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

2013-01-21 Thread Alexander Kjeldaas

Or this.  It seems that you must compile with DEBUG for the mutex check.
 This enables error-checking mutexes on posix.

Alexander

diff --git a/rts/posix/OSThreads.c b/rts/posix/OSThreads.c
index ae31966..e07221d 100644
--- a/rts/posix/OSThreads.c
+++ b/rts/posix/OSThreads.c
@@ -91,7 +91,8 @@ initCondition( Condition* pCond )
 void
 closeCondition( Condition* pCond )
 {
-  pthread_cond_destroy(pCond);
+  int ret = pthread_cond_destroy(pCond);
+  CHECKM(ret == 0, RTS Bug! Someone is waiting on condvar ret=%d., ret);
   return;
 }

@@ -165,7 +166,8 @@ initMutex(Mutex* pMut)
 void
 closeMutex(Mutex* pMut)
 {
-pthread_mutex_destroy(pMut);
+int ret = pthread_mutex_destroy(pMut);
+CHECKM(ret == 0, RTS Bug! Destroying held mutex ret=%d, ret);
 }

 void


On Mon, Jan 21, 2013 at 10:14 AM, Alexander Kjeldaas 
alexander.kjeld...@gmail.com wrote:

 I think you can test this theory with this patch.  If a thread is waiting
 on the task-cond condition variable which is matched up with task-lock,
 then pthread_cond_destroy will return EBUSY, which must always be a bug in
 the RTS.

 Alexander

 diff --git a/rts/posix/OSThreads.c b/rts/posix/OSThreads.c
 index ae31966..0f12830 100644
 --- a/rts/posix/OSThreads.c
 +++ b/rts/posix/OSThreads.c
 @@ -91,7 +91,8 @@ initCondition( Condition* pCond )
  void
  closeCondition( Condition* pCond )
  {
 -  pthread_cond_destroy(pCond);
 +  int ret = pthread_cond_destroy(pCond);
 +  CHECKM(ret == 0, RTS BUG! Someone is waiting on condvar %d., ret);
return;
  }



 On Mon, Jan 21, 2013 at 8:18 AM, Alexander Kjeldaas 
 alexander.kjeld...@gmail.com wrote:


 I just looked at this code and since I don't know the code I can't give
 you good solutions, but for others watching this thread the links might
 prove interesting.

 My main theory is that you do have some other thread in FFI-land while
 you are fork()ing.  The task-cond, task-lock seems to be related to this
 (see quoted comments below).

 Also, pthread_mutex_destroy is undefined if the lock is locked, so I am
 guessing that the task-lock is somehow locked when it shouldn't be.

 It isn't clear from your description whether this is consistently
 happening on Linux, or whether this only sometimes happens.

 The forkProcess() code seems to hold all capabilities during fork, but
 that does not include FFI-land threads AFAIU.

 Assuming that this happens only rarely, I am trying to understand what
 happens if the thread that is in FFI-land returns to the RTS (in the
 parent) after fork(), but before the freeTask() in the child.  Based on the
 descriptions I read, it seems likely that this thread will try to inspect
 task-cap, which requires holding task-lock.

 That would in turn make the pthread_mutex_destroy in the child invalid.

 https://github.com/ghc/ghc/blob/master/rts/Task.h#L57

 
  ...
  When a task is migrated from sleeping on one Capability to another,
its task-cap field must be modified.  When the task wakes up, it
will read the new value of task-cap to find out which Capability
it belongs to.  Hence some synchronisation is required on
task-cap, and this is why we have task-lock.

If the Task is not currently owned by task-id, then the thread is
either

  (a) waiting on the condition task-cond.  The Task is either
  (1) a bound Task, the TSO will be on a queue somewhere
  (2) a worker task, on the spare_workers queue of task-cap.
...
 

 freeTask:
 https://github.com/ghc/ghc/blob/master/rts/Task.c#L142

 the comment in freeTask refers to this test:

 https://github.com/ghc/testsuite/blob/master/tests/concurrent/should_run/conc059.hs

 That test calls the RTC from C which then forkIOs off actions that are
 outstanding when the RTS exits.

 in forkProcess, child code
 https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L1837

 It look like all this code supports the notion that some other thread can
 be in foreign code during the fork call.

 discardTasksExcept
 https://github.com/ghc/ghc/blob/master/rts/Task.c#L305


 Alexander


 On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner 
 mark.lentcz...@gmail.com wrote:

 Sorry to be reviving this thread so long after but I seem to be
 running into similar issues as Michael S. did at the start.

 In short, I'm using forkProcess with the threaded RTS, and see
 occasional hangs:

- I see these only on Linux. On Mac OS X, I never do.
- I'm using GHC 7.4.2
- I noticed the warning in the doc for forkProcess, but assumed I
was safe, as I wasn't holding any shared resources at the time of the 
 fork,
and no shared resources in the program are used in the child.
- WIth gdb, I've traced the hang to here in the run-time: forkProcess
 discardTasksExcept  freeTask  closeMutex(task-lock)
 pthread_mutex_destroy

 The discussion in this thread leaves me with these questions:

- Is there reason to think the situation has gotten better in 7.6
and later?
- Isn't the only reason *System.Process*

Re: [Haskell-cafe] [ANN] tls-extra 0.6.1 - security update, please upgrade.

2013-01-21 Thread Joachim Breitner

Hi,

Am Sonntag, den 20.01.2013, 17:21 +0100 schrieb Vincent Hanquez:
 On Sun, Jan 20, 2013 at 11:01:22AM +0100, Joachim Breitner wrote:
  Debian ships tls-extras 0.4.6 in what will become wheezy, and due to the
  freeze upgrading to a new major upstream release is not acceptable. 
  
  Would it be possible for you to create a 0.4.6.1 with this bugfix
  included?
 
 (wow, the tls packages stack are quite obsolete)
 
 Apart from the fact that it took me a while to rebase to this version,
 I just uploaded 0.4.6.1. it compiles but got minimal testing.

thanks, uploaded to Debian and on its way into the wheezy suite.

Greetings,
Joachim

-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Up-front Unit Testing in Haskell

2013-01-21 Thread Jan Stolarek

Thanks for a nice tutorial. A couple of months ago I spent quite some time 
trying to figure out 
how to write tests in Haskell, which resulted in this blog post: 
http://ics.p.lodz.pl/~stolarek/blog/2012/10/code-testing-in-haskell/ 
Sadly there are no test-framework providers for hspec and dostest - this would 
make using them a 
whole lot easier.

Janek

Dnia poniedziałek, 21 stycznia 2013, Mateusz Kowalczyk napisał:
 Quite informative, thank you. It was nice to see how to combine the
 suites together as most places only show how to use one.

 The mention about Travis CI is also much appreciated; it seems like a
 really good project and I will definitely be using it in the future.


 Mateusz Kowalczyk

 On 21/01/13 02:55, Kazu Yamamoto (山本和彦) wrote:
  #Resending due to the lack of URL.
 
  Hello cafe,
 
  Just FYI:
 
  I wrote an tutorial, Up-front Unit Testing in Haskell. It is about
  how to use doctest, hspec and Cabal.
 
  https://github.com/kazu-yamamoto/unit-test-example/blob/master/markdown/
 en/tutorial.md
 
  Enjoy!
 
  --Kazu
 
  ___
  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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

2013-01-21 Thread Chris Dornan

I am also sorry to be late on this but I have run into the same problem
trying to demonise a programme on 7.4.2. My solution was to get a shell
wrapper to run the daemon in debug mode (I.e., sans fork) and get the shell
script to do the demonising.

Other than this I have found the threaded RTS to be sound and I am quite
reliant on it. So, where things that run threaded are concerned, no
forkProcess calls for me until I can better understand this better.

If anybody does think they understand what is going on here it would be
great if they could write it up. IMHO, either the current notes on
forkProcess don't go far enough, or there is a bug needing a workaround
until the platform gets fixed.

Chris

From:  Mark Lentczner mark.lentcz...@gmail.com
Date:  Sunday, 20 January 2013 23:15
To:  haskell haskell-cafe@haskell.org
Cc:  Mike Meyer m...@mired.org
Subject:  Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

Sorry to be reviving this thread so long after but I seem to be running
into similar issues as Michael S. did at the start.

In short, I'm using forkProcess with the threaded RTS, and see occasional
hangs:
* I see these only on Linux. On Mac OS X, I never do.
* I'm using GHC 7.4.2
* I noticed the warning in the doc for forkProcess, but assumed I was safe,
as I wasn't holding any shared resources at the time of the fork, and no
shared resources in the program are used in the child.
* WIth gdb, I've traced the hang to here in the run-time: forkProcess 
discardTasksExcept  freeTask  closeMutex(task-lock) 
pthread_mutex_destroy
The discussion in this thread leaves me with these questions:
* Is there reason to think the situation has gotten better in 7.6 and later?
* Isn't the only reason System.Process is safer because it does an immediate
exec in the child? Alas, I really want to just fork() sometimes.
* Is it really true that even if my program has no shared resources with the
child, that the IO subsystem and FFI system do anyway? Surely the RTS would
take care of doing the right thing with those, no?
* There should be no concern with exec w.r.t. library invariants since exec
is wholesale replacement - all the libraries will reinitialize. Is there a
problem here I'm missing?
Alas, I've stopped using the threaded RTS until I understand this better.

- Mark
___ 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] forkProcess, forkIO, and multithreaded runtime

2013-01-21 Thread Alexander Kjeldaas

While trying to dig around this morning I started adding clang-style thread
locking annotations to the source code.  These can be very handy and I
found at least one place where the documented locking policy doesn't seem
to match what is happening.

Here is an example with annotations, and what might or might not be a bug.
 With these annotations, clang will be able to prove whether the program
obeys the locking regime or not.

But this is of course only one part of the RTS, but the locking can be
pretty interesting in itself.

Does anyone else feel that this sort of annotations would help?

Alexander

diff --git a/rts/Task.c b/rts/Task.c
index e6781a1..1e499dc 100644
--- a/rts/Task.c
+++ b/rts/Task.c
@@ -25,12 +25,12 @@

 // Task lists and global counters.
 // Locks required: all_tasks_mutex.
-Task *all_tasks = NULL;
+Task *all_tasks GUARDED_BY(all_tasks_mutex) = NULL;

-nat taskCount;
-nat workerCount;
-nat currentWorkerCount;
-nat peakWorkerCount;
+nat taskCount GUARDED_BY(all_tasks_mutex);
+nat workerCount GUARDED_BY(all_tasks_mutex);
+nat currentWorkerCount GUARDED_BY(all_tasks_mutex);
+nat peakWorkerCount GUARDED_BY(all_tasks_mutex);

 static int tasksInitialized = 0;

@@ -339,9 +339,11 @@ void updateCapabilityRefs (void)
 ACQUIRE_LOCK(all_tasks_mutex);

 for (task = all_tasks; task != NULL; task=task-all_next) {
+ACQUIRE_LOCK(task-lock);
 if (task-cap != NULL) {
 task-cap = capabilities[task-cap-no];
 }
+RELEASE_LOCK(task-lock);

 for (incall = task-incall; incall != NULL; incall =
incall-prev_stack) {
 if (incall-suspended_cap != NULL) {



On Mon, Jan 21, 2013 at 2:14 PM, Chris Dornan ch...@chrisdornan.com wrote:

 I am also sorry to be late on this but I have run into the same problem
 trying to demonise a programme on 7.4.2. My solution was to get a shell
 wrapper to run the daemon in debug mode (I.e., sans fork) and get the shell
 script to do the demonising.

 Other than this I have found the threaded RTS to be sound and I am quite
 reliant on it. So, where things that run —threaded are concerned, no
 forkProcess calls for me until I can better understand this better.

 If anybody does think they understand what is going on here it would be
 great if they could write it up. IMHO, either the current notes on
 forkProcess don't go far enough, or there is a bug needing a workaround
 until the platform gets fixed.

 Chris

 From: Mark Lentczner mark.lentcz...@gmail.com
 Date: Sunday, 20 January 2013 23:15
 To: haskell haskell-cafe@haskell.org
 Cc: Mike Meyer m...@mired.org
 Subject: Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

 Sorry to be reviving this thread so long after but I seem to be
 running into similar issues as Michael S. did at the start.

 In short, I'm using forkProcess with the threaded RTS, and see occasional
 hangs:

- I see these only on Linux. On Mac OS X, I never do.
- I'm using GHC 7.4.2
- I noticed the warning in the doc for forkProcess, but assumed I was
safe, as I wasn't holding any shared resources at the time of the fork, and
no shared resources in the program are used in the child.
- WIth gdb, I've traced the hang to here in the run-time: forkProcess
 discardTasksExcept  freeTask  closeMutex(task-lock)
 pthread_mutex_destroy

 The discussion in this thread leaves me with these questions:

- Is there reason to think the situation has gotten better in 7.6 and
later?
- Isn't the only reason *System.Process* is safer because it does an
immediate exec in the child? Alas, I really want to just fork()sometimes.
- Is it really true that even if my program has no shared resources
with the child, that the IO subsystem and FFI system do anyway? Surely the
RTS would take care of doing the right thing with those, no?
- There should be no concern with exec w.r.t. library invariants since
exec is wholesale replacement - all the libraries will reinitialize.
Is there a problem here I'm missing?

 Alas, I've stopped using the threaded RTS until I understand this better.

 - Mark
 ___ 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: Hquery 0.1

2013-01-21 Thread Tycho Andersen

Hi cafe,

I've written a library called hquery, which can be used to manipulate
xmlhtml trees (and has a similar selector syntax to jquery, hence the
name). This enables easy manipulation and content generation from html
templates. If you're familiar with Lift's CssSels, this is basically
an implementation of those in haskell.

This is my first foray into haskell, so any critiques of the code or API are
welcome :-)

Hquery: http://hackage.haskell.org/package/hquery-0.1.0.1

Examples:
http://hackage.haskell.org/packages/archive/hquery/0.1.0.1/doc/html/Text-Hquery.html

\t

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

Re: [Haskell-cafe] XCode Dependency for HP on Mac

2013-01-21 Thread Andrew H Bridge

Tom Murphy amindfv at gmail.com writes:

 
 Is there a way to install HP without XCode? Could there be in the
 future? I'm tired of dealing with Apple's constant upgrade
 requirements, registration requirements, etc., and it seems like a
 small function that XCode actually performs in the Haskell development
 toolchain.
 Again, I'm ignorant of the details and I'm sorry if this is ranty, but
 I'd love to hear your reactions.
 
 Thanks!
 Tom
 

Hi,

I know this is an old thread, but it came up on Google when I was 
searching around for an answer to this. So maybe I can still help 
someone.

10.6 users can use this installer on GitHub 
https://github.com/kennethreitz/osx-gcc-installer. It 
installs gcc and a few other bits and pieces (less than a GB to install). 
Then you can install the Haskell Platform. It's worked for me so far! Enjoy!

Thanks,
Andrew


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

Re: [Haskell-cafe] XCode Dependency for HP on Mac

2013-01-21 Thread Mark Lentczner

As the README at that repository states, For 10.7 and later Apple now
distributes a Command Line Tools package on the developer site. When I
build and release the Haskell Platform, I confirm that works when just this
package is installed (rather than all of Xcode).

The Command Line Tools from Apple include not only the compiler and bin
tools that GHC needs, but also the full suite of development headers and
library stubs.

Many people's OS X woes with HP have stemmed from non-standard development
installations. If at all possible, I suggest you stick with
Apple's distributions.

Please keep us appraised of how it works for you after you've used it for a
bit. I'm curious if, should you start installing some of Hackage's more
complicated packages, if it continues to work out.

- Mark (HP release manager)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] XCode Dependency for HP on Mac

2013-01-21 Thread Andrew H Bridge

Mark Lentczner mark.lentczner at gmail.com writes:

 
 As the README at that repository states, For 10.7 and later Apple now
 distributes a Command Line Tools package on the developer site.
 When I build and release the Haskell Platform, I confirm that works 
 when just this package is installed (rather than all of Xcode).

 [Message continues]
 
 - Mark (HP release manager)
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe at haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 


Hi Mark,

I will keep you updated, the issue is that I refuse to upgrade to 10.7 or later,
many of the brilliant features from Snow Leopard were entirely ruined and
I still see people complaining about having trouble with it on my model of
MacBook.

So for 10.6 users, this 3rd part installer is the only option I could find!

Thanks,
Andrew


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

Re: [Haskell-cafe] [Haskell] ANNOUNCE: MFlow 0.2

2013-01-21 Thread Alberto G. Corona

The template look is very simple but it uses a lot of dynamic code behind

I changed the template to something more light.

http://haskell-web.blogspot.com.es/


2013/1/20 bri...@aracnet.com

 On Thu, 17 Jan 2013 16:07:41 +0100
 Alberto G. Corona  agocor...@gmail.com wrote:

 
  The entry in my blog, with the announcement and the philosophy behind
  http://haskell-web.blogspot.com.es/2013/01/announce-mflow-02.html
 

 FYI
 That page never comes up for me.  I just see spinning gears.
 iceweasel 10.0.7

 Brian




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

Re: [Haskell-cafe] regular expression sub-expression matching

2013-01-21 Thread Nicolas Bock

Hi Roman and Bob,

thanks a lot for the help. I ended up using getAllTextSubmatches as
explained by Bob, since I had that package already installed on my system.
Works great!

Thanks,

nick



On Fri, Jan 18, 2013 at 5:52 PM, Bob Ippolito b...@redivi.com wrote:

 Note that Haskell doesn't convert \( to \\( like Python does, so the
 regex string has been changed. It's not so easy to figure out how to use
 this library from the documentation because of all the typeclass trickery.

 h import Text.Regexp.Posix (getAllTextSubmatches, (=~))
 h getAllTextSubmatches (M(1,2) = 0.1e-3; =~ M\\(([0-9]+),([0-9]+)\\)
 *= *([0-9.eE-]+);) :: [String]
 [M(1,2) = 0.1e-3;,1,2,0.1e-3]

 If it doesn't match, you'll get an empty list. You can join the tail of
 the match list together with Data.List.intercalate, and print it out with
 putStrLn. The if null case would just return ().

 To demonstrate some of the typeclass trickery going on here, you could ask
 for the results as an Array with Int indexes of String.

 h import Text.Regexp.Posix (getAllTextSubmatches, (=~))
 h import Data.Array ((!), Array)
 h let matches = getAllTextSubmatches (M(1,2) = 0.1e-3; =~
 M\\(([0-9]+),([0-9]+)\\) *= *([0-9.eE-]+);) :: Array Int String
 h matches
 array (0,3) [(0,M(1,2) = 0.1e-3;),(1,1),(2,2),(3,0.1e-3)]
 h map (matches !) [1..3]
 [1,2,0.1e-3]

 -bob

 On Fri, Jan 18, 2013 at 3:25 PM, Nicolas Bock nicolasb...@gmail.comwrote:

 Hello list,

 I was wondering whether there is a way to do what the following python
 code does in haskell:

 import re

 result = re.compile(M\(([0-9]+),([0-9]+)\) *=
 *([0-9.eE-]+);).search(M(1,2) = 0.1e-3;)
 if result:
   print(result.group(1), result.group(2), result.group(3))

 Basically I would like to pattern match parts of a string and return the
 matches. I have looked at Text.Regex.Posix but (of course I might just not
 have understood the functions in there properly) it seems as if it does not
 provide anything like python's re module.

 Thanks already,

 nick


 ___
 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] [ANN] tls-extra 0.6.1 - security update, please upgrade.

2013-01-21 Thread Vincent Hanquez

On Sun, Jan 20, 2013 at 08:27:07PM +0100, Alexander Kjeldaas wrote:
 Regarding testing, it looks like the Tests directory hasn't been updated to
 cover this bug.  What would really give confidence is a set of tests
 encoding fixed security vulnerabilities in OpenSSL (and similar libraries).
  That should also give you a lot of confidence in your library.
 
 But anyways, this is fantastic work you're doing.  Keep it up!

Thanks,

Regarding tests, a good test suite is a hard and long job.

Some security properties are just insanely hard to codify, and
some others need a lots of tests.

My time being very limited, it's hard to pull off, but i have plan to
add some tests for the certificate validation functions. Specially
since i want to harden some functions a bit more, and it will come handy
to verify i'm not breaking anything :-)

-- 
Vincent

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

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

Re: [Haskell-cafe] [ANN] tls-extra 0.6.1 - security update, please upgrade.

Re: [Haskell-cafe] Up-front Unit Testing in Haskell

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

[Haskell-cafe] ANN: Hquery 0.1

Re: [Haskell-cafe] XCode Dependency for HP on Mac

Re: [Haskell-cafe] XCode Dependency for HP on Mac

Re: [Haskell-cafe] XCode Dependency for HP on Mac

Re: [Haskell-cafe] [Haskell] ANNOUNCE: MFlow 0.2

Re: [Haskell-cafe] regular expression sub-expression matching

Re: [Haskell-cafe] [ANN] tls-extra 0.6.1 - security update, please upgrade.

13 matches

Site Navigation

Mail list logo

Footer information