headers
Hal Daume III | 3 Dec 2002 18:46
Picon
Favicon

Re: getting a Binary module into the standard libs

Does flushByte n flush to the next 2^n bit or byte?

--
Hal Daume III

 "Computer science is no more about computers    | hdaume <at> isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

On 14 Nov 2002, Alastair Reid wrote:

> 
> > 2) The proposals for flushByte, as I see it, are:
> 
> >   a) flushBytes h n aligns the stream to the next 2^n byte (bit?)
> > boundary
> 
> I think this is the right one to do.  It would probably only be used
> with n=8,16,32 but I doubt the extra generality will cost anything.
> 
> >   b) flushBytes h m n aligns the stream such that the position p
> > satisfies (p = n) mod 2^m
> 
> I mentioned this style of interface but I doubt we'd need it in practice.
> If we do, it can always be added later as a separate function.
> 
> 
> > 3) I think we can all agree that we should buffer BinIOs.  There are
> > a few questions, given this:
> 
> >   a) Should multiple threads be allowed to write the same BinHandle
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Meacham | 5 Dec 2002 07:33
Favicon

Posix.installHandler issues.

I cant seem to figure out how to do one-shot signals in haskell, the
problem is that signals are queued to be run on a haskell thread so I
cannot do a 'installHandler _ Default _' without the possiblility of
more signals coming in before the thread gets scheduled. Proposed
solution: add another argument to Posix.installHandler which takes a
list of flags as described in sigaction(3) (including SA_ONESHOT). I
apologize if i am misinterpreting the behavior of my program.
	John

--

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john <at> foo.net
---------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Volker Stolz | 5 Dec 2002 11:30
Picon
Picon

Re: Posix.installHandler issues.

In local.libraries, you wrote:
> solution: add another argument to Posix.installHandler which takes a
> list of flags as described in sigaction(3) (including SA_ONESHOT). I
> apologize if i am misinterpreting the behavior of my program.

I'm not sure that the other flags are (generally) useful or apply
at all to Haskell (e.g. SA_NODEFER: is a Haskell-handler equivalent
to a C signal handler?).

Furthermore, it's probably not necessary to break the API. How about
a new function with the parameter indicating ONESHOT or not and then
expressing installHandler through this? I don't like primInstallHandler
or installHandler', so if somebody has a suggestion...

BTW: One might argue that you could simply write your own in-Haskell
signalstack by simply setting MVars/Semaphores in the signal handler
and then have one Concurrent Haskell thread which decides what to do
with those 'signals'. 
--

-- 
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
Permalink | Reply | 0 comments |
headers
Hal Daume III | 10 Dec 2002 19:03
Picon
Favicon

RE: getting a Binary module into the standard libs

Hi again all,

I've got a somewhat functioning new Binary module for GHC which supports
bit writes.  I've written a small test script to make sure simple things
work...it essentially looks like this:

data BinItem = ByteItem Word8
             | BitItem  Int Word8   -- num_bits bits
             | FlushItem            -- flush byte
             | forall a . (Eq a, Binary a, Show a) => BinaryItem a  --
some arbi
trary data
             | forall a . (Eq a, Show a) => PutItem a (BinHandle -> a ->
IO ()) 
(BinHandle -> IO a)

on which Eq is defined (I use unsafePerformIO to cast the forall'd
elements).

then we have test functions which essentially open up a binMem or a binIO
and write a list of BinItems to it, then read them back.  We can then
check if what we read back is the same as what we wrote.

The tests I have run are:

byteTest = map ByteItem [1,2,3,4,5]

bitTest1 = [BitItem 3 6, FlushItem]
bitTest2 = [BitItem 3 6, BitItem 4 9, BitItem 1 0, FlushItem]
bitTest3 = [BitItem 6 10, BitItem 6 10, FlushItem]
(Continue reading)

Permalink | Reply | 503 comments |
headers
John Meacham | 11 Dec 2002 03:46
Favicon

showUnique

how about adding a show instance for Unique in Data.Unique?  oftentimes
arbitrary unique labels need to be generated, but 'hashUnique' doesnt
guarentee the returned Int is unique. there is no way to add this
functionality outside of the Data.Unique module since Unique is opaque.
	John

--

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john <at> foo.net
---------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Andrew J Bromage | 11 Dec 2002 04:05
Favicon
Gravatar

Re: showUnique

G'day all.

On Tue, Dec 10, 2002 at 06:46:27PM -0800, John Meacham wrote:

> how about adding a show instance for Unique in Data.Unique?  oftentimes
> arbitrary unique labels need to be generated, but 'hashUnique' doesnt
> guarentee the returned Int is unique. there is no way to add this
> functionality outside of the Data.Unique module since Unique is opaque.

What do you propose that the show method would actually return on
a Unique?  I think this is far from obvious, as any such method
would break the opacity of Unique, and hence limit the number of
ways that it could be implemented.

Cheers,
Andrew Bromage
Permalink | Reply | 1 comment |
headers
John Meacham | 11 Dec 2002 04:30
Favicon

Re: showUnique

no constraints at all, what is shown is implementation dependent, with
the only requirement being that:

u == u' iff showUnique u == showUnique u'

a string can contain an arbitrary amount of data so any internal
representation can be shown, note there is no readUnique, we need not be
able to go in the other direction. also, Ord is not maintained, just Eq.

I suppose a nice constraint would be that the string be made up of
alphanumeric values only this can be trivially done and would make it
more useful.

	John

On Wed, Dec 11, 2002 at 02:05:51PM +1100, Andrew J Bromage wrote:
> G'day all.
> 
> On Tue, Dec 10, 2002 at 06:46:27PM -0800, John Meacham wrote:
> 
> > how about adding a show instance for Unique in Data.Unique?  oftentimes
> > arbitrary unique labels need to be generated, but 'hashUnique' doesnt
> > guarentee the returned Int is unique. there is no way to add this
> > functionality outside of the Data.Unique module since Unique is opaque.
> 
> What do you propose that the show method would actually return on
> a Unique?  I think this is far from obvious, as any such method
> would break the opacity of Unique, and hence limit the number of
> ways that it could be implemented.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Russell | 11 Dec 2002 18:22
Picon
Favicon

Re: showUnique

I support the suggestion of providing
   instance Show Unique
I would also support having
   instance Read Unique

As John says, the representation of a Unique value as a String should be
completely undefined except that
   u == u' iff showUnique u == showUnique u'

In UniForM we have a similar type to Unique which also instances
   (Eq,Ord,Show,Read)
One advantage of instancing Show is that it makes it easier to debug programs
which use Unique values.  Read is more debatable, but I'm sure we use it somewhere.
Permalink | Reply | 0 comments |
headers
Hal Daume III | 17 Dec 2002 17:45
Picon
Favicon

RE: getting a Binary module into the standard libs

Hi, another update wrt speed of bit writes; it makes me think it might not
be worthwhile to split the instances or anything like that.  I'm still
looking for some comments though (hint hint).

A small program writes 1 million maybe ints to a binmem, 1/5 of which are
nothings, 4/5s of which are just ints.  Note that both the nothing and the
just int take 1 bit (mod 1 byte), so the bit offset is increasing by one
every write, independent of which we're writing.  the best case in terms
of speed occurs when we write just int and we're already written 7 bits
(so writing the int doesn't have to much around with bit stuff).

Anyway, here are the speed results, averaged over 3 runs, with
optimization on and off:

                       Optimization
                  level 0        level 2
                  -------        -------
bits    read        2446            195
        write      23157           1729

bytes   read        1822            177
        write      13769           1563

So, moral #1 is: never use binary without optimization or you will be
waiting a long time.  Moral #2 is that when optimization is on, bit-based
writes take about 11% longer to read and write.

We can pretty easily calculate the space savings, directly.  An Int is 4
bytes, we write 800000 of them = 3200000 bytes.  When we use bits, we also
write 1 million bits = 125000 bytes.  When we use bytes, we also write 1
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alastair Reid | 18 Dec 2002 10:58
Picon

Re: getting a Binary module into the standard libs


Hal Daume <hdaume <at> ISI.EDU> writes:
> Hi, another update wrt speed of bit writes; it makes me think it
> might not be worthwhile to split the instances or anything like
> that.  I'm still looking for some comments though (hint hint).

If the performance difference is just 11%, it sounds like it's best to
keep the instances combined.  (I'm assuming both versions were
carefully written for speed - seems like a safe assumption given the
author!)  The speed difference is likely to continue as the speed
difference between processors,memory,etc. and disks,system
calls,etc. continues to grow.

--
Alastair Reid                 alastair <at> reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/
Permalink | Reply | 2 comments |

Gmane