headers
Andrew Coppin | 4 Jul 21:54

Re: ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

Paul Johnson wrote:
> Andrew Coppin wrote:
>> Well, no, because now I'm going to have to spend a few hours trying 
>> to find out what CIE is before I can even use that library.
>>
>> I think really it's just aimed at a different problem. It looks like 
>> it's trying to specify actual real-world colours. [It's news to me 
>> that this isn't fundamentally impossible...] I'm only trying to 
>> specify colours on a computer screen. And as we all know, computer 
>> screens aren't calibrated in any way, and the same RGB value looks 
>> different on each display. But then, I'm only trying to write a 
>> fractal generator, so CIE specifications are somewhat overkill here. ;-)
> Your display may not be calibrated, but those used for graphic design 
> certainly are.

Indeed. And if you're in any kind of position where you *care* about 
such things, you should be using color, not AC-Colour. If, however, you 
just want to throw together pretty pictures, AC-Colour is simpler and 
easier. Different libraries for slightly different tasks. ;-)

> On the package naming front: I appreciate your wish to avoid just 
> having another "colour" library.  But "AC_Colour" doesn't help much.  
> "Simple_colour" might be better.

Mmm, yeah. Naming everything with "AC" precludes name clashes and 
doesn't require too much thinking. Coming up with a better name requires 
thinking about what actually makes your package unique. And, of course, 
if another package comes along, that analysis may change. (E.g., I seem 
to recall there's a "newbinary" package which has actually been long 
since superceeded - so not so "new" any more!) If I name my package
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Coppin | 4 Jul 19:53

ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

OK, so having released AC-HalfInteger, I got slightly carried away and 
released three other small packages. These are packages that many 
programs I write all end up using. I'm forever copying these files, so I 
made them into actual bonafide packages.

http://hackage.haskell.org/package/AC-Vector-1.1.1

This provides two types, Vector2 and Vector3, which are unboxed vectors 
of Doubles, with arithmetic, dot product and cross product, and a few 
other useful items.

http://hackage.haskell.org/package/AC-Colour-1.1.1

This provides two types, Colour and Colour8. Both implement simple RGB 
colour types with arithmetic. Colour has unboxed Double fields, and 
Colour8 has unboxed Word8 fields. My usual workflow is to do all the 
image generation with Colour, and to convert to Colour8 just before the 
data hits the I/O channels. You can, however, do arithmetic directly on 
Colour8. (I haven't extensively tested that it works properly though...)

http://hackage.haskell.org/package/AC-EasyRaster-GTK-1.1.1

This is a layer over Gtk2hs. As you all probably know, Gtk2hs provides a 
Cairo binding that makes vector graphics wonderfully easy. However, 
*bitmapped* graphics is darned tricky. I basically had to sit in the 
#haskell channel with Duncan for a few hours trying to figure out how 
the hell to do it. This knowledge is now codified in the above package. 
Load it up and you don't need to know a thing about GTK; you can just 
create an ImageBuffer, write some pixels to it (efficiently!), save it 
to disk or display it on screen. (But you *can* access the underlying
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Coppin | 4 Jul 19:47

Re: ANN: HalfInteger-1.1.1

Alexander Dunlap wrote:
> Couple of suggestions:
>
> - You should put an (Integer i) => constraint on the halve function so
> that it becomes impossible to create invalid HalfIntegers.
>   

Right. Currently you can *make* such a HalfInteger. You just won't be 
able to *do* anything with it afterwards. It would probably be more 
sensible to just add a constraint there.

> - The documentation for toHalfInteger is truncated. Also, why can't
> you make the rounding more predictable?
>   

...wow. OK, I'm looking at the source, and it seems I must have got 
distracted at that moment or something, because I just 100% didn't 
actually finish writing the documentation! o_O That's pretty special. ;-)

As I *should* have written, the rounding for something like 
toHalfInteger 0.25 is kind of unpredictable; but if you do toHalfInteger 
0.5, the result is *guaranteed* to be exact. All the functions are 
carefully tuned to work correctly on things which really are half 
integers, and to give plausible results otherwise. Just don't let your 
life depend on 0.25 being mapped to exactly a half or to exactly zero...

> Nice work!
>   

Heh, thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cetin Sert | 4 Jul 19:31
Gravatar

Flow Graphs for Language-independent Code Representation

Hi *^o^*,

I'm working on a source code transformation project for numerical automatic differentiation for Fortran and C.

I would love to know the best Haskell way/package available today to represent procedural (non-OO) code in a language-independent manner. Any tips or resource, paper references are most welcome!

Regards,
Cetin Sert

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 0 comments |
headers
Andrew Coppin | 4 Jul 16:19

Small Haddock question

This is irritating me now... Suppose I have something like the following:

zero = 0 :: Int
one = 1 :: Int
two = 2 :: Int
three = 3 :: Int

How do I add Haddock comments to the end of each line? For some reason, 
Haddock doesn't like either of

zero = 0 :: Int -- | Zero
zero = 0 :: Int -- ^ Zero

Either way it whinges about parse errors. How do I make it shut up and 
stop being so dense at me? :-} It's damned obvious what I want it to do...
Permalink | Reply | 1 comment |
headers
Uwe Hollerbach | 4 Jul 09:38

following up on space leak

Good evening, all, following up on my question regarding space leaks,
I seem to have stumbled across something very promising. I said I was
using this tiny function "lastOrNil" to get the last value in a list,
or the empty (scheme) list if the haskell list was empty. The uses of
it were all of the form

    lastOrNil (mapM <something> <some list>)

so I wrote a different function mapML to do this directly:

> mapML fn lst = mapMLA (List []) fn lst
>   where mapMLA r _ [] = return r
>         mapMLA ro fn (x:xs) =
>            do rn <- fn x
>               mapMLA rn fn xs

This isn't an accumulator, it's a replacer (or, if you like, the
"accumulation" is "drop the old one on the floor"), it starts out with
the scheme empty list that I want as the default, and it never even
builds the list which it'll just dump an instant later. Shazam! Memory
usage dropped by roughly an order of magnitude in my little Collatz
benchmark, and incidentally runtime improved by 25% or so as well. The
horror! :-)

Having tasted blood, I will of course be continuing to benchmark...
but not tonight.

Uwe
Permalink | Reply | 2 comments |
headers
Uwe Hollerbach | 4 Jul 07:34

space leak hints?

Good evening, all, I wonder if I could tap your collective wisdom
regarding space leaks? I've been messing about with haskeem, my little
scheme interpreter, and I decided to see if I could make it run
reasonably space-efficiently. So far... no.

Here's what I tried: I wrote a tiny scheme program to compute Collatz
sequences for successive numbers, starting from 1 and incrementing
forever (well, in principle). Because real scheme implementations are
fully tail-call-optimized, this'll run in constant memory; I checked
that with mzscheme, and it does indeed work. With my little
interpreter, that's not the case: memory usage grows continually,
although apparently less-than-linearly. I've built the interpreter
with the profiling stuff described on the wiki and in RWH Ch 25 turned
on and have made a few runs with that; I stuck the postscript plot
that's the result of one of those runs onto my web site at
http://www.korgwal.com/haskeem/run2.ps.

The full source to the interpreter is a little large to paste into
this message; it's available on my web site, and also on hackage. But
according to the plot, there appear to be three main memory allocation
issues, and they seem to all be related, if I'm reading stuff
correctly. The core of the interpreter is a function, evalLisp, which
evaluates scheme forms. There are of course a fair number of different
forms, but the largest generic usage is "evaluate each of a list of
forms, returning the value of the last of them as the overall result".
In order to express that in a couple of different places, and to
accomodate the possibility of an empty list, I have a really tiny
function lastOrNil which just calls "last" on a (haskell) list,
checking for the possibility of an empty list, and returning a haskeem
LispVal object:

> lastOrNil = liftM lON
>   where lON [] = List []
>        lON l = last l

(sorry, proportional fonting may be throwing this off).

It's this function which is directly implicated in two of the top
three memory pigs, and nearly directly in the third one as well. If I
could eliminate the memory growth in these three cost centers, I would
already capture over 90% of the growth in this benchmark, which would
make me very happy indeed. But I don't really understand what is going
on here. It seems entirely plausible, indeed likely, that the list
which I'm traversing there is not fully evaluated. So I've tried
adding 'seq' to this function. Uhhh... from memory, I dumped it after
it didn't work, I had

> lastOrNil = liftM lON
>   where lON [] = List []
>               lON (l:[]) = l
>               lON (l:ls) = seq l (lON ls)

(again, proportional fonting might mess me up here.)

As I said, I dumped this after it made no difference whatsoever. I
also tried bang-patterns in a couple of places, strictness annotation
of my basic LispVal types... nothing. It all made exactly no
difference, as far as I could tell. I've tried a couple of google
searches, but haven't come up with anything better than what I've
already described. So I'm a stumped chump!

I'd be grateful for any suggestions... thanks in advance!

Uwe
Permalink | Reply | 0 comments |
headers
John Ky | 4 Jul 03:44

How to pretty print code efficiently

Hi,

Currently I'm pretty printing code by building arrays of strings and calling indent.  For example:

instance JavaPrintableNamed AST.EnumeratedType where
   javaLinesNamed parentName (AST.EnumeratedType memberDefinitions) =
      [ "public enum " ++ asJavaId(parentName)
      , "{"
      ] ++ memberCodeLines ++
      [ "}"
      , ""
      ]
      where
         memberCodeLines = indent $ javaLines memberDefinitions

The indent function takes a list of strings and adds an indent to the beginning of every line.

I can imagine this to be very inefficient as it builds many strings and concatenates them.

In Ruby, I might do the same thing like this:

class EnumeratedType < JavaPrintableNamed
   def writeTo(writer)
      writer.print "public enum "
      writer.puts self.asJavaId
      writer.puts "{"
      writer.indent do
         self.memberDefinitions.writeTo(writer)
         writer.puts
      end

where above, the writer.indent takes care of the indent, and everything is appended to a stream, which doesn't seem so bad in terms of efficiency.

I'm looking for a way to do something similar in Haskell.

Anyone can give me a hand?

Thanks

-John

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 3 comments |
headers
Günther Schmidt | 4 Jul 01:10

Cont, ContT and IO()


Hi,

I've got an IO action, some file system IO, traversing one level only and  
iterating over files found. I wish to build in an "early" exit, ie. if an  
IO action in the loop encounters a particular value I want it to abort the  
loop.

Now so far, pls don't shoot, I have done this by throwing IO Exceptions  
and catching them. I'm trying to rewrite this using Continuatios / callCC  
but can't figure out where to place what.

I certainly don't have the intuition yet and funny enough not even in RWH  
I could find some Cont/ContT examples.

Would someone please draw me an example?

Günther
Permalink | Reply | 12 comments |
headers
Patai Gergely | 3 Jul 22:20
Favicon

ANN: bloxorz clone

Hello all,

This post is not about my own creation, it's just a little fun program
written by a student of mine. You can install the bloxorz package to try
it out, and read more about its background on my blog:

http://just-bottom.blogspot.com/2009/07/playing-and-learning.html

Gergely

--

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are
Permalink | Reply | 0 comments |
headers
Jinjing Wang | 3 Jul 19:21
Gravatar

Help needed to pick a better name then "hack"

Hack is such an inconvenient name for a package, may I get some
inspiration from renaming it?

Also, is there an idiom to use when upgrading package name on hackage?

Best,

--

-- 
jinjing
Permalink | Reply | 2 comments |

Gmane