#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams | Owner: simonpj
Type: bug | Status: new
#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams | Owner: simonpj
Type: bug | Status: new
#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams | Owner: simonpj
Type: bug | Status: new
#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams | Owner:
Type: bug | Status: new
#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams | Owner:
Type: bug | Status: new
#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams| Owner:
Type: bug | Status
#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter: joeyadams| Owner:
Type: bug | Status
Ryan Ingram wrote:
Heinrich Apfelmus wrote:
However, even in a demand-driven implementation, there is one optimization
that I would like make: when there are multiple external events, say e1 and
e2, the network splits into subnetworks that react only to one of the
inputs. For instance, your
On Tue, Apr 26, 2011 at 11:44 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
However, even in a demand-driven implementation, there is one optimization
that I would like make: when there are multiple external events, say e1 and
e2, the network splits into subnetworks that react only
Ryan Ingram wrote:
Apfelmus, I hope you don't abandon your efforts, at least for the selfish
reason that I enjoy reading your blog entries about trying to implement it!
:D My reasoning was that a temporary demand-driven implementation would
allow me to release the library sooner; I want
or
unsafeInterleaveIO. A behavior is a value, which when evaluated at a
specific time would have to either block its evaluation until input
could be read, or check the input at that particular time.
Is there any other way of implementing external behaviors besides that?
Yes, there are other ways, see
can tell, with classic FRP implementations (those which
use behaviors as a first-class abstraction), the only way to create a
behavior or
event based on some external input (for instance keypresses or
microphone input) is to do something with unsafePerformIO or
unsafeInterleaveIO. A behavior
As far as I can tell, with classic FRP implementations (those which
use behaviors as a first-class abstraction), the only way to create a
behavior or
event based on some external input (for instance keypresses or
microphone input) is to do something with unsafePerformIO or
unsafeInterleaveIO
a
behavior or
event based on some external input (for instance keypresses or
microphone input) is to do something with unsafePerformIO or
unsafeInterleaveIO. A behavior is a value, which when evaluated at a
specific time would have to either block its evaluation until input
could be read, or check
Mail fail, haha. Code fixed.
For example:
-- Library functions for a hypothetical FRP system
pollEvent :: IO [a] - Event a
behavior :: a - Event a - Behavior a
accumB :: b - (b - a - b) - Event a - Behavior b
accumE :: b - (b - a - b) - Event a - Event b
union :: Event a - Event a - Event a
#1657: throwTo + unsafeInterleaveIO oddness
-+--
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone
#1657: throwTo + unsafeInterleaveIO oddness
-+--
Reporter: guest | Owner:
Type: bug | Status: closed
Priority: normal | Milestone
#1657: throwTo + unsafeInterleaveIO oddness
---+
Reporter: guest |Owner:
Type: bug | Status: merge
Priority: normal |Milestone
#1657: throwTo + unsafeInterleaveIO oddness
---+
Reporter: guest |Owner:
Type: bug | Status: merge
Priority: normal |Milestone
#1657: throwTo + unsafeInterleaveIO oddness
---+
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal |Milestone
Jonathan Cast jonathancc...@fastmail.fm writes:
Couldn't you just substitute catch exceptions with unsafePerformIO
here, and make the same argument?
This puzzled me, until I realized you meant `unsafeInterleaveIO'.
Aargh, yes of course! Sorry about that.
Assuming you mean
What does this mean again? I'm working on the assumption that
`context-sensitive' means `under some (not necessarily compositional
and/or continuous and/or monotonic) equivalence relation/
I'm using contexts as expressions with holes, as used for evaluation
contexts in operational semantics,
exceptions in IO then it doesn't matter,
it's just a little extra non-determinism and IO has plenty of that
already.
Couldn't you just substitute catch exceptions with unsafePerformIO
here, and make the same argument?
This puzzled me, until I realized you meant `unsafeInterleaveIO'.
That's
On 17/03/2009, at 1:13 PM, Jonathan Cast wrote:
[Totally OT tangent: How did operational semantics come to get its
noun?
The more I think about it, the more it seems like a precís of the
implementation, rather than a truly semantic part of a language
specification.]
I haven't followed the
code of some pure function, thus being able to differentiate
funcitions that are normally indistinguishable?
I've tried to follow this discussion, but I don't quite understand
what's so bad about unsafeInterleaveIO - or rather, what's so uniquely
bad about it. It seems the same issues can be found
So that first step already relies on IO (where the two are equivalent).
Come again?
The first step in your implication chain was (without the return)
throw (ErrorCall urk!) = 1
== evaluate (throw (ErrorCall urk!)) = evaluate 1
but, using evaluation only (no context-sensitive IO), we
On Tue, 2009-03-17 at 12:40 +, Claus Reinke wrote:
So that first step already relies on IO (where the two are equivalent).
Come again?
The first step in your implication chain was (without the return)
throw (ErrorCall urk!) = 1
== evaluate (throw (ErrorCall urk!)) = evaluate
Hi,
On 2009/03/16, at 10:04, wren ng thornton wrote:
next r = do n - readIORef r
writeIORef r (n+1)
return n
Now, if I use unsafeInterleaveIO:
main = do r - newIORef 0
x - do a - unsafeInterleaveIO (next r)
b - unsafeInterleaveIO
, Does it means that in optimization, a compiler may replace
implementation of a pure function that have different order of
evaluation, so order of actions would be different in some
environments?
order of actions is meaningless in pure functions, so yes. And
that's why unsafeInterleaveIO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yusaku Hashimoto wrote:
| I was studying about what unsafeInterleaveIO is.I understood
| unsafeInterleaveIO takes an IO action, and delays it. But I couldn't
| find any reason why unsafeInterleaveIO is unsafe.
I think it depends on what we want
pretty sure I haven't yet seen a case where this applies
to unsafeInterleaveIO.
I don't think unsafeInterleaveIO on its own can do this.
However, I disagree with your description of what unsafe should be
used for. unsafe calls out the need for the programmer to prove
that what they are doing
. Whether that is due to type safety
(unsafeCoerce) or breaking the assumptions of the compiler
(unsafePerformIO, unsafeInterleaveIO, unsafeIOToST), depends on the
situation.
Of course, unsafeIOToST can also break the type system, because you can write:
unsafePerformIO m = runST (unsafeIOToST m
On Sun, 15 Mar 2009, Ryan Ingram wrote:
unsafeInterleaveIO allows embedding side effects into a pure
computation. This means you can potentially observe if some pure
value has been evaluated or not; the result of your code could change
depending how lazy/strict it is, which is very hard
On Sun, 15 Mar 2009, Claus Reinke wrote:
import Data.IORef
import Control.Exception
main = do
r - newIORef 0
let v = undefined
handle (\(ErrorCall _)-print hireturn 42) $ case f v of
0 - return 0
n - return (n - 1)
y - readIORef r
print y
I don't see what this has to do
On Mon, 2009-03-16 at 22:12 +0100, Henning Thielemann wrote:
On Sun, 15 Mar 2009, Claus Reinke wrote:
import Data.IORef
import Control.Exception
main = do
r - newIORef 0
let v = undefined
handle (\(ErrorCall _)-print hireturn 42) $ case f v of
0 - return 0
n -
On Mon, 2009-03-16 at 14:17 -0700, Jonathan Cast wrote:
On Mon, 2009-03-16 at 22:12 +0100, Henning Thielemann wrote:
On Sun, 15 Mar 2009, Claus Reinke wrote:
import Data.IORef
import Control.Exception
main = do
r - newIORef 0
let v = undefined
handle (\(ErrorCall
On Mon, 2009-03-16 at 22:01 +, Duncan Coutts wrote:
On Mon, 2009-03-16 at 14:17 -0700, Jonathan Cast wrote:
On Mon, 2009-03-16 at 22:12 +0100, Henning Thielemann wrote:
On Sun, 15 Mar 2009, Claus Reinke wrote:
import Data.IORef
import Control.Exception
main = do
exception handling which allows to catch programming errors.
And which I have a sneaking suspicion actually *is* `unsafe'. Or, at
least, incapable of being given a compositional, continuous semantics.
A semantics for imprecise exceptions
On Tue, 2009-03-17 at 01:16 +, Claus Reinke wrote:
exception handling which allows to catch programming errors.
And which I have a sneaking suspicion actually *is* `unsafe'. Or, at
least, incapable of being given a compositional, continuous semantics.
A semantics for imprecise
Hello,
I was studying about what unsafeInterleaveIO is.I understood
unsafeInterleaveIO takes an IO action, and delays it. But I couldn't
find any reason why unsafeInterleaveIO is unsafe.
I have already read an example in
http://www.haskell.org/pipermail/haskell-cafe/2009-March/057101.html
says
unsafeInterleaveIO allows embedding side effects into a pure
computation. This means you can potentially observe if some pure
value has been evaluated or not; the result of your code could change
depending how lazy/strict it is, which is very hard to predict!
For example:
-- given
f
On Sun, 2009-03-15 at 13:02 -0700, Ryan Ingram wrote:
unsafeInterleaveIO allows embedding side effects into a pure
computation. This means you can potentially observe if some pure
value has been evaluated or not; the result of your code could change
depending how lazy/strict it is, which
will *always* print 0.
I'm confused. I though if f was strict, then my program *always*
printed 1?
But not if you switch the (x - ...) and (y - ...) parts:
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
return 1
y - readIORef r
x - case f v
should have no effect.
But if you switch them, the program will *always* print 0.
I'm confused. I though if f was strict, then my program *always*
printed 1?
But not if you switch the (x - ...) and (y - ...) parts:
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
return 1
y - readIORef r
x - case f v of
0 - return 0
n - return (n - 1)
print y
Now the IORef is read before the case has a chance to trigger the
writing
?
But not if you switch the (x - ...) and (y - ...) parts:
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
return 1
y - readIORef r
x - case f v of
0 - return 0
n - return (n - 1)
print y
of possible implementations, they *are* equivalent.
So the ordering in fact *doesn't* matter.
Hum. Whether the programme prints 0 or 1 depends on whether writeIORef r 1
is done before readIORef r.
That depends of course on the semantics of IO and unsafeInterleaveIO.
In so far as the compiler is free
of IO and unsafeInterleaveIO.
In so far as the compiler is free to choose there, it can indeed produce
either result with either programme.
But I think
Haskell 's I/O monad provides the user with a way to specify the sequential
chaining of actions, and an implementation is obliged
is done before readIORef r.
That depends of course on the semantics of IO and unsafeInterleaveIO.
In so far as the compiler is free to choose there, it can indeed produce
either result with either programme.
But I think
Haskell 's I/O monad provides the user with a way to specify
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
return 1
x - case f v of
0 - return 0
n - return (n - 1)
y - readIORef r
print y
-- a couple of examples:
f x = 0 -- program prints 0
-- f x = x -- program prints 1
f is pure
the programme prints 0 or 1 depends on whether writeIORef r
1 is done before readIORef r.
That depends of course on the semantics of IO and unsafeInterleaveIO.
In so far as the compiler is free to choose there, it can indeed produce
either result with either programme.
But I think
Am Montag, 16. März 2009 00:47 schrieb Jonathan Cast:
On Mon, 2009-03-16 at 00:14 +0100, Daniel Fischer wrote:
However, I understand
unsafeInterleaveIO allows IO computation to be deferred lazily. When
passed a value of type IO a, the IO will only be performed when the
value
On Mon, 2009-03-16 at 01:04 +0100, Daniel Fischer wrote:
Am Montag, 16. März 2009 00:47 schrieb Jonathan Cast:
On Mon, 2009-03-16 at 00:14 +0100, Daniel Fischer wrote:
However, I understand
unsafeInterleaveIO allows IO computation to be deferred lazily. When
passed a value
Yusaku Hashimoto wrote:
Hello,
I was studying about what unsafeInterleaveIO is.I understood
unsafeInterleaveIO takes an IO action, and delays it. But I couldn't
find any reason why unsafeInterleaveIO is unsafe.
I have already read an example in
http://www.haskell.org/pipermail/haskell-cafe
On Sun, Mar 15, 2009 at 1:56 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
But not if you switch the (x - ...) and (y - ...) parts:
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
return 1
y - readIORef r
x - case f v
On Sun, 2009-03-15 at 18:11 -0700, Ryan Ingram wrote:
On Sun, Mar 15, 2009 at 1:56 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
But not if you switch the (x - ...) and (y - ...) parts:
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
a = LazyIO {runLazyIO :: StateT RunAll IO a}
data RunAll = RunAll
deriving Show
instance Monad LazyIO where
return x = LazyIO $ return x
x = f = LazyIO $
mapStateT unsafeInterleaveIO . runLazyIO . f =
mapStateT unsafeInterleaveIO (runLazyIO x)
instance MonadIO LazyIO where
On Thu, 1 Jan 2009, Brandon S. Allbery KF8NH wrote:
On 2009 Jan 1, at 16:44, Henning Thielemann wrote:
If it is generally possible to use unsafeInterleaveIO such that it
executes actions in the right order, wouldn't this allow the definition
of a general lazy IO monad?
I thought
On Sat, 3 Jan 2009, Henning Thielemann wrote:
On Thu, 1 Jan 2009, Brandon S. Allbery KF8NH wrote:
On 2009 Jan 1, at 16:44, Henning Thielemann wrote:
If it is generally possible to use unsafeInterleaveIO such that it
executes actions in the right order, wouldn't this allow the definition
I think I have a very similar problem to the currently discussed
WriterT [w] IO is not lazy in reading [w].
I want to defer IO actions, until they are needed, but they shall be
executed in order. If I call unsafeInterleaveIO, they can be executed in
any order. I understand that hGetContents does
On 2009 Jan 1, at 16:44, Henning Thielemann wrote:
If it is generally possible to use unsafeInterleaveIO such that it
executes actions in the right order, wouldn't this allow the
definition
of a general lazy IO monad?
I thought unsafeInterleaveIO and users of it (readFile, hGetContents
Henning Thielemann schlepp...@henning-thielemann.de wrote:
If it is generally possible to use unsafeInterleaveIO such that it
executes actions in the right order, wouldn't this allow the
definition of a general lazy IO monad?
The question is what right order means.
Let B1..Bn be some
On Fri, 2 Jan 2009, Achim Schneider wrote:
Henning Thielemann schlepp...@henning-thielemann.de wrote:
If it is generally possible to use unsafeInterleaveIO such that it
executes actions in the right order, wouldn't this allow the
definition of a general lazy IO monad?
The question is what
On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider bars...@web.de wrote:
There are no lazy monads. Monads imply explicit sequencing...
Huh? How are you defining lazy monad?
--
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
On Fri, 2 Jan 2009, Achim Schneider wrote:
There are no lazy monads. Monads imply explicit sequencing... writing
I think this is an extremely bad thing to say and is a source of
misunderstanding about monads and evaluation. Most monads _are_ lazy, and
it is important to understand that
Henning Thielemann lemm...@henning-thielemann.de wrote:
On Fri, 2 Jan 2009, Achim Schneider wrote:
Henning Thielemann schlepp...@henning-thielemann.de wrote:
If it is generally possible to use unsafeInterleaveIO such that it
executes actions in the right order, wouldn't this allow
On 2009 Jan 1, at 20:08, David Menendez wrote:
On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider bars...@web.de
wrote:
There are no lazy monads. Monads imply explicit sequencing...
Huh? How are you defining lazy monad?
We've had this discussion before; somewhere in the archives is an
Achim Schneider bars...@web.de wrote:
[...]
actually, even better:
main = do
acts - unsafeInterleaveIO getActs
putStrLn dumdidum
sequence_ acts
, which, at least on my machine, prints dumdidum before asking for foo.
--
(c) this sig last receiving data processing entity. Inspect
Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote:
On 2009 Jan 1, at 20:08, David Menendez wrote:
On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider bars...@web.de
wrote:
There are no lazy monads. Monads imply explicit sequencing...
Huh? How are you defining lazy monad?
We've had
On Thu, Jan 1, 2009 at 8:29 PM, Brandon S. Allbery KF8NH
allb...@ece.cmu.edu wrote:
On 2009 Jan 1, at 20:08, David Menendez wrote:
On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider bars...@web.de wrote:
There are no lazy monads. Monads imply explicit sequencing...
Huh? How are you defining
David Menendez d...@zednenem.com wrote:
On Thu, Jan 1, 2009 at 8:29 PM, Brandon S. Allbery KF8NH
allb...@ece.cmu.edu wrote:
On 2009 Jan 1, at 20:08, David Menendez wrote:
On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider bars...@web.de
wrote:
There are no lazy monads. Monads imply
External sort is on hackage at
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/external-sort
Ben, I forgot to correct your name, but I will fix it soon.
Thomas.
2008/10/11 Ben [EMAIL PROTECTED]:
Fine with me, except my last name is Lee not Midfield. Thanks for
doing this.
Ben
I kinda-sorta half-cabalized it at
darcs get http://darcsdump.dreamhosters.com/external-sort (untested
via cabal install but mostly done)
As soon as my project gets approved I'll put it up on hackage.
If Ben wants it under his account at hackage of course I'll defer to him.
Thomas.
2007/7/18
Hello,
Haskell is non-strict but not necessarily lazy. So it’s possible that an
expression is reduced to WHNF although it is not used yet. Could this “early
reduction” also happen to outputs of unsafeInterleaveIO actions (which might
trigger the action too early)? While I’d expect those
Wolfgang,
Haskell is non-strict but not necessarily lazy. So it's possible
that an expression is reduced to WHNF although it is not used yet.
Could this early reduction also happen to outputs of
unsafeInterleaveIO actions (which might trigger the action too early)?
While I'd expect those
On Wed, 2008-08-27 at 01:48 +0200, Wolfgang Jeltsch wrote:
Hello,
Haskell is non-strict but not necessarily lazy. So it’s possible that an
expression is reduced to WHNF although it is not used yet. Could this “early
reduction” also happen to outputs of unsafeInterleaveIO actions (which
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component
#2095: add new forms of unsafePerformIO and unsafeInterleaveIO
+---
Reporter: duncan | Owner:
Type: proposal| Status: closed
Priority: normal | Milestone
#2095: add new forms of unsafePerformIO and unsafeInterleaveIO
+---
Reporter: duncan | Owner:
Type: proposal| Status: new
Priority: normal | Milestone
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component
Sounds reasonable. 'unsafeInterleaveIO' defers computation of 'vp'
until it is actually needed. At this time the viewport might have
changed.
That sound reasonable indeed, but the viewport does not change and the
values I get are really random. I'll try to make minimal example to
demonstrate
I'm experiencing strange behavior when executing some Haskell OpenGL
code inside unsafeInterleaveIO.
For example,
vp - get GL.viewport
returns garbage, as if the opengl context is not correctly set.
Is this to be expected? Or is it likely a bug on my side?
Thanks,
Peter
On Fri, 9 May 2008, Peter Verswyvelen wrote:
I'm experiencing strange behavior when executing some Haskell OpenGL code
inside unsafeInterleaveIO.
For example,
vp - get GL.viewport
returns garbage, as if the opengl context is not correctly set.
Sounds reasonable. 'unsafeInterleaveIO
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component
#2095: add new forms of unsafePerformIO and unsafeInterleaveIO
+---
Reporter: duncan | Owner:
Type: proposal| Status: new
Priority: normal | Milestone
#2094: add two new forms of unsafePerformIO and one of unsafeInterleaveIO
-+--
Reporter: duncan| Owner:
Type: proposal | Status: new
Priority: normal
#2095: add new forms of unsafePerformIO and unsafeInterleaveIO
-+--
Reporter: duncan| Owner:
Type: proposal | Status: new
Priority: normal| Component
#2094: add two new forms of unsafePerformIO and one of unsafeInterleaveIO
---+
Reporter: duncan |Owner:
Type: proposal| Status: closed
Priority: normal
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component
#1657: throwTo + unsafeInterleaveIO oddness
+---
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8 branch
#1657: throwTo + unsafeInterleaveIO oddness
---+
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal |Milestone
#1657: throwTo + unsafeInterleaveIO oddness
-+--
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone
On Tue, Jul 17, 2007 at 04:16:29AM -0500, Ben wrote:
hi folks --
a haskell newbie here, searching for comments and wisdom on my code.
i had a project to try to implement external sort in haskell as a
learning exercise. (external sort is sorting a list that is too large
to fit in main
becomes a bit tricky, if you're
seeking file handles around underneath Data.ByteString.Lazy's nose.
but late this night after not thinking about it for a while i had a
brainstorm: rewrite hGetContents to keep the handle position in the
right place! it's all about judicious use of unsafeInterleaveIO
Ben wrote:
a haskell newbie here, searching for comments and wisdom on my code.
i had a project to try to implement external sort in haskell as a
learning exercise. (external sort is sorting a list that is too large
to fit in main memory, by sorting in chunks, spooling to disk, and
then
use of unsafeInterleaveIO.
it seems to be rather fast, strangely faster than the usual sort at
times. it also seems to have nice memory characteristics, though not
perfect. it's hard to test because the normal sort function takes
too much RAM on large lists, making my computer swap like
in the
right place! it's all about judicious use of unsafeInterleaveIO.
it seems to be rather fast, strangely faster than the usual sort at
times. it also seems to have nice memory characteristics, though not
perfect. it's hard to test because the normal sort function takes
too much RAM
midfield:
hi --
thanks for the useful comments! i will definitely go through them
carefully. unfortunately for this code (but fortunately for me) i
defend my dissertation on monday so i'm a little distracted right
now.
i'm more than happy to donate this code or whatever
1 - 100 of 148 matches
Mail list logo
