headers
Claus Reinke | 1 May 2009 01:00

Re: Google SoC: Space profiling reloaded

> http://socghop.appspot.com/student_project/show/google/gsoc2009/haskell/t124022468245
> 
> There's less than a month left before I'm supposed to jump into coding,
> and I'd love to hear about any little idea you think would make this
> project even better! I created a project page with a rough draft of what
> I intend to concentrate on, but the issue tracker is obviously begging
> for content, so feel encouraged to populate it. :)
> 
> http://code.google.com/p/hp2any/

Hi there,

I'm sure lots of Haskellers are looking forward to profiling improvements!-)

The wxHaskell applications page

http://wxhaskell.sourceforge.net/applications.html

mentions 

http://dready.org/projects/HPView/

which seems relevant.

Shortening the song and dance needed to get profiles would be nice
(eliminating the PS viewer dependency in the process).
So would not having to select profile type in advance (and not having
to repeat the profile runs again and again, with only one view each time).

I assume you're only going to look into visualization, not semantics?-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 May 2009 01:13
Picon
Picon
Favicon

Re: How to install HOpenGL to Windows?

On Thu, 2009-04-30 at 23:31 +0100, Claus Reinke wrote:
> > The thing is, it doesn't really matter if autoconf macros work fine for
> > every Unix ever invented. The Windows users simply cannot use packages
> > with configure scripts. They complain about it a lot. We can call them
> > foolish for not installing cygwin/mingw, but they will not do it and
> > instead will simply not use our software and/or continue to complain.
> 
> "Windows users" - that's a lot of different people to generalize over.

Yes, I was generalising. There are those users who are prepared, even
happy to install cygwin, and there's everyone else.

> >From what I've heard, most complaints are about assumptions made 
> by non-windows users that turn out not to hold on windows,
> causing things to fail on windows. Which seems reason enough for
> failure reports, otherwise known as "complaints".
> 
> If someone wants to use a unix shell on an unknown platform, they 
> should at least check that one exists there or -even better- provide 
> one, not just assume that there'll always be one (and then be surprised 
> about getting complaints from "those windows users"). Same for
> autoconf, make & co.

You mean that we should be shipping a haskell platform with a full copy
of mingw + all the tools to make configure scripts run? I doubt that'll
make people happy. They'll complain about it not being "native".

> If someone mixes up GCC's standard layout, they need to adjust
> "everything" for those changes, and when that turns out to be rather
> difficult, it is no surprise if GCC seems unable to pick the right
(Continue reading)

Permalink | Reply | 1 comment |
headers
Claus Reinke | 1 May 2009 01:58

Re: How to install HOpenGL to Windows?

>> If someone wants to use a unix shell on an unknown platform, they 
>> should at least check that one exists there or -even better- provide 
>> one, not just assume that there'll always be one (and then be surprised 
>> about getting complaints from "those windows users"). Same for
>> autoconf, make & co.
> 
> You mean that we should be shipping a haskell platform with a full copy
> of mingw + all the tools to make configure scripts run? I doubt that'll
> make people happy. They'll complain about it not being "native".

The platform includes GHC, which already includes mingw (GCC)!-)

What I meant was a cabal package bundling the pieces of msys (sh,
autoconf, make,..). And, no, the haskell platform doesn't need this,
so it should be a separate package. But cabal install should know
that this package would be nice to have at hand if building a package
that uses build-type:configure on windows.

>>just fixed:
>> http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12
> In principle there is no problem with finding the mingw headers on
> Windows. All we need is that the rts or base package specify them in the
> include-dirs in the package registration info. Cabal uses the same info.

In practice, we have instructions like these circulating (these being
examples of the better kind, as they actually got things working):
http://joelhough.com/blog/2008/04/14/haskell-and-freeglut-at-last/
http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/

And I've lost count of the number of times the finding of mingw
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dimitry Golubovsky | 1 May 2009 05:33
Picon
Gravatar

Few Alex questions

Hi,

Q1: I am trying to create an Alex equivalent of the following flex file:

http://code.haskell.org/yc2js/es-idl/lexer.ll (lexer for Web IDL which
is a dialect of OMG IDL)

I haven't been able to find Alex equivalent for the following line:

PoundSign               ^{WhiteSpace}*#

that is any amount of whitespace at the beginning of line followed by '#'

I defined a  <at> WhiteSpace macro some place earlier, but Alex gives me
parser error on the line I created:

 <at> PoundSign         =      ^ <at> WhiteSpace*#

in the position 28 that is position of ' <at> ', next to caret, that is,
caret is not recognized by Alex.

Can beginning of line (caret) be recognized by Alex?

Q2: The original line says:

MultiLineComment        \/\*(([^*])|(\*[^/]))*\*\/

basically same as comments in C or Java.

I had to prefix star and slash even within square brackets with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Belka | 1 May 2009 06:09
Picon
Favicon

[tryReadAdvChan :: AdvChan a -> IO (Maybe a)] problems


Hi!

I need this function with requirement of heavy reads, *possibly under DDoS
attack*. 
Was trying to write such function, but discovered some serious problems of 
** possible racings, 
** possible starvations 
** unbalance: readAdvChan users may get better service than ones of
tryReadAdvChan
These are totally unacceptible for my case of DDoS risk.

Actually, am I wrong thinking, that it can't be helped - and the degradation
from cute concurency synchronization model of Chan is unavoidable? 

My (untested) code:
-------------------------------------------
-------------------------------------------
module AdvChan ( AdvChan
               , newAdvChan
               , readAdvChan
               , writeAdvChan
               , writeList2AdvChan
               , advChan2StrictList
               , withResourceFromAdvChan
               , tryReadAdvChan
               , isEmptyAdvChan
               ) where

import Control.Concurrent.Chan
(Continue reading)

Permalink | Reply | 3 comments |
headers
Don Stewart | 1 May 2009 07:21
Favicon
Gravatar

The Haskell Reddit is 1 year old

Just a reminder, the Haskell Reddit is live and active:

    http://www.reddit.com/r/haskell/

It is a a place for fast, daily, comprehensive news about what's going
on in the Haskell community, combining blogs, mail, irc, ghc's patches,
the freaking types <at>  mailing list! It's all here, with comments.

Enjoy. Contribute.

-- Don
Permalink | Reply | 1 comment |
headers
Grigory Sarnitskiy | 1 May 2009 08:06
Picon
Favicon
Gravatar

Array Binary IO & molecular simulation

Hello!

I'm interested in computer simulation of molecular systems, especially liquids. Maybe some would say Haskell is far from best choice in the case, but I really like the ease of writing programs in Haskell.

So I wonder of existing projects of such type, both Molecular dynamics and Monte Carlo methods. I've got also some technical questions. Now I'm using 2D DiffUArray to represent particle positions during the simulation (when there are lots of array updates). Is this reasonably fast (I want to use pure external interface of DiffArray)?

During the simulation each nth cycle the current position is stored for further processing. I haven't done this stage yet. To store the position I'm going to turn DiffUArray to UArray and write it in the file using tools of Data.Binary. Unfortunately I failed to produce the working code to write lots of 2D UArrays and then to read them. I know how to write several arrays in a file, but not how to read them back. Could someone please help me? Just to show how I've thought of storing several arrays in one file:

import Data.Array.Unboxed
import Data.Binary
import qualified Data.ByteString.Lazy as BL

a = listArray ((1,1),(3,2)) [3,4,5,6,7,8] :: UArray (Int, Int) Float
b = listArray ((1,1),(3,2)) [9,10,11,12,13,14] :: UArray (Int, Int) Float

encodeFile2 f = BL.appendFile f . encode

run = do encodeFile "Results.txt" a
     encodeFile2 "Results.txt" b

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 8 comments |
headers
Ivan Lazar Miljenovic | 1 May 2009 08:47
Picon
Gravatar

ANNOUNCE: graphviz-2009.5.1


I'd like to announce version 2009.5.1[1] of the graphviz[2] library,
less than a week since Matthew Sackman passed maintainership onto me[3].
The graphviz library provides a Haskell interface to the GraphViz[4]
program.

[1] http://hackage.haskell.org/packages/archive/graphviz/2009.5.1/graphviz-2009.5.1.tar.gz
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphviz
[3] http://www.mail-archive.com/haskell <at> haskell.org/msg21994.html
[4] http://graphviz.org

Major changes with this release are:

* Supports polyparse >= 1.1 (the previous version didn't work with 1.3).

* Requires base == 4.* (i.e. GHC 6.10.*) due to the new exception
  handling.

* Includes functions from my Graphalyze [5] library for actually running
  the various GraphViz commands, etc.

* Slight API breakages:

  - dirCommand, undirCommand and commandFor no longer return String, but
    GraphvizCommand

  - Data.GraphViz.ParserCombinators is no longer exported by the Cabal
    file, since I see no need for anyone to require acccess to this.  If
    this is a problem for you, please let me know and I'll re-export it.

* A lot more Haddock documentation.

* A darcs repository is now available [6].  Patches are welcome!

[5] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze
[6] http://code.haskell.org/graphviz

Plans for the future:

* Add support for Data.Graph-style graphs (maybe even making it generic
  such that custom graph types can be used).

* Allow the user to choose whether the graph is directed or undirected.

* Include all attributes offered by the Dot language.

* Remove (or at least minimise) usage of extensions to increase portability.

Oh, and to pre-empt Don, this is already available in the Gentoo-Haskell
overlay ;-)

--
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
IvanMiljenovic.wordpress.com
Permalink | Reply | 0 comments |
headers
Bernie Pope | 1 May 2009 09:16
Picon
Gravatar

Re: Few Alex questions

2009/5/1 Dimitry Golubovsky <golubovsky <at> gmail.com>

<snip>

Can beginning of line (caret) be recognized by Alex?

You can match the start of a line using a (left) context on a rule. See the docs here:


Where it says: "The left context matches the character which immediately precedes the token in the input stream. The character immediately preceding the beginning of the stream is assumed to be ‘\n’. The special left-context ‘^’ is shorthand for ‘\n^’."

Alex also supports right contexts too.

<snip>

Is this correct understanding that if we want to match any character
except for an asterisk, then Alex would like to see [^\*] rather than
[^*]? And [^\/] rather than [^/]?

Or would it be better to use a hex code for the asterisk and slash?

In a character set you must escape certain special characters. The list of special characters is specified in the docs here:


The key line is:

   $special    = [\.\;\,\$\|\*\+\?\#\~\-\{\}\(\)\[\]\^\/]

I'd try to avoid character codes where possible.

Cheers,
Bernie. 
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 0 comments |
headers
maarten | 1 May 2009 09:29
Picon

Re: Thread priority?

Hi all,

Some two year I wrote a library to change thread priorities in Windows, 
including another library that allows real time processing. With this 
you can play midi files real time and without interruption from the OS. 
(Manipulating thread priorities is really easy in Windows, real time 
uninterrupted processing a little more complicated).

Actually, I thought this problem was already resolved 
(haskore-realtime), but if there is interest I can see if I can dust 
them off, although I'm sure there will be still lots of things to 
improve. Right now I'm working in linux only, so it may take a few days 
to get a suitable xp version. (Actually, I would be really interested in 
a linux port, but have little time right now. Perhaps this library can 
help: http://sourceforge.net/projects/high-res-timers ?)

Kind regards,

Maarten

Christopher Lane Hinson wrote:
>
> Is there any interest or movement in developing thread priority or any 
> other realtime support in Haskell?
>
> Right now, if I have tasks that need to be responsive in real time, 
> even if the realtime needs are very soft, it seems that the only 
> option is to try to ensure that at least one hardware thread is kept 
> clear of any other activity.
>
> To be very useful to me, thread priority would not need to come with 
> very strict guarantees, but there would need to be a way to make sure 
> that `par` sparks and DPH inherit the priority of the sparking thread.
>
> In part I ask because I'm working on a small library to support a 
> degree of cooperative task prioritization.
>
> Friendly,
> --Lane
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Permalink | Reply | 2 comments |

Gmane