Re: [Haskell] [Haskell.org GSoC] Accepted Proposals

2014-04-21 Thread Conrad Parker
Hi,

are there long descriptions somewhere? the trac page linked from melange
seems to have not been updated since 2012:

https://ghc.haskell.org/trac/summer-of-code/report/1

I'd be interested to see the milestones and expected outcomes for some of
the projects :)

Conrad.

On 22 April 2014 06:56, Edward Kmett  wrote:

> I'm pleased to announce the list of accepted student proposals for
> haskell.org for the Google Summer of Code 2014.
>
>Title Student Mentor  Adding profiling support to GHCJS -- JavaScript
> backend for GHC Ömer Sinan Aǧacan Luite Stegeman  Concurrent Lock-Free
> Hash Map for Haskell Mathias Bartl Ryan Newton  Darcs: Hashed Files and
> Cache Marcio Díaz Eric Kow  HDBC Improvements Edisach Nicolas Wu  Darcs:
> History reordering: performance and features Ale Gadea Guillaume Hoffmann  
> Implement
> Constraint-Based Layout in Diagrams Allan Gardner Daniel Bergey  Lensify
> Diagrams Niklas Haas Brent Yorgey  An Efficient Computational Algebra and
> Symbolic Linear Algebra Library in Haskell Hiromi ISHII Edward Kmett  Complete
> plugins-ng "low-level", "filewatch", and "cabal" packages Kẏra Greg Weber  
> Build
> Interactive Websites with GHCJS and Sodium Kyle Raftogianis Luite Stegeman  
> Pandoc
> improvements: Embedded base64 images and EPUB 3.0 reader Matthew Pickering 
> John
> MacFarlane  Agda-like Interaction Mode for Emacs Alejandro Serrano David
> Raymond Christiansen  Debugging tool for GHCJS Nathan van Doorn Luite
> Stegeman  Flesh out features of Hackage 2 Chris Wong Duncan Coutts
> You can explore the abstracts of the accepted proposals at
>
> http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell
>
> I would like to take a moment to offer congratulations to all of the
> students we were able to accept into the program this year.
>
> That said, I would also like to offer my condolences to those students
> whom we were not able to bring into the program. We received 14 slots in
> total this year - more than we ever received in past years - yet still not
> nearly enough to accept all of the excellent proposals we received this
> time around. Please consider applying again next year.
>
> I am looking forward to working with you on another Summer of Code, and I
> hope we can all make an effort as a community to be welcoming and to help
> you in your projects.
>
> If you have any questions or concerns about the process, please feel free
> to email me or chase me down on #haskell-gsoc on irc.freenode.net.
>
> -Edward Kmett
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell] Summer of Code questions

2007-03-09 Thread Conrad Parker

Hi,

just following up from this and some subsequent discussion on #haskell:

On 09/03/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote:

duncan.coutts:
> On Fri, 2007-03-09 at 00:39 +0100, Wolfgang Jeltsch wrote:
>
> > > > First, what organization is Haskell.org?
> > > > Is this a real organization, i.e., a legal entity?
> > >
> > > No.  (Unlike e.g. the Apache Foundation.)
> >
> > Doesn???t this create problems in conjunction with the Summer of Code or is
> > Google tolerant regarding the legal status of participating organizations?
>
> It didn't cause any problem last year.

Indeed. The majority of .orgs are ad hoc developer groups. Very few are
actually legal entitites (like Apach or NetBSD).


Some second-hand info regarding discussion on the mentoring
organisation's discussion group (non-public, hence no archive URL):

 kfish: there was some discussion about umbrella
organizations and incorporation
 kfish: Leslie recommended organizations incorporate, or get
the Software Freedom Law Center or SPI to handle their financials for
them
 but I can't find a statement that this was required
 I think the idea is that if you have a legal footprint, they
can pay that, and individuals don't have to go through the hassle of
getting a US taxpayer ID number just so they can tell the US gov't
they're not taxable

As I also mentioned on #haskell, there is probably no problem for
haskell.org because it had a successful SoC last year. When I talked
with Leslie after linux.conf.au, she mentioned that she was very very
happy with haskell.org's participation last year because the people
from the Haskell community were so friendly, kind and patient :-)

cheers,

Conrad (kfish).
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell] [ANNOUNCE] network-address-0.2.0

2011-09-07 Thread Conrad Parker
On 7 September 2011 20:03, Sebastian Nowicki  wrote:
> Hi All,
>
> I'm pleased to announce the release of network-address v0.2.0. The
> library provides data structures and textual representation of network
> addresses (IPv4, IPv6, subnets).
>
> Major changes in this release:
>
>  * Revised Address type class (readAddress was moved out of the class,
> readsAddress :: String -> ReadS a was added for better error
> reporting)
>  * Better support for IPv6 parsing (compressed zeroes).
>  * Implementation of RFC5952 (a recommendation for IPv6 text
> representation). Most notably showAddress for IPv6 compresses zeroes.
>
> Example GHCi session:
>
> *Data.Network.Address> let ip = readAddress "2001:db8:0:0:0::1" :: IPv6
> *Data.Network.Address> ip
> IPv6 2306139568115548160 1
> *Data.Network.Address> showAddress ip
> "2001:db8::1"
> *Data.Network.Address> let subnet = readSubnet "2001:db8::1/56" :: IPSubnet 
> IPv6
> *Data.Network.Address> showSubnet subnet
> "2001:db8::/56"
> *Data.Network.Address> ip `member` subnet
> True
>

Hi,

given that readAddress can parse the output of showAddress, and
readSubnet can parse the output of showSubnet, is there any reason not
to use these for the implementation of Show and Read instances?

I notice that currently you deriving Show and Read instances:

-- |The abstract data structure to represent an IPv4 address.
data IPv4 = IPv4 !Word32
deriving (Eq, Ord, Bounded, Show, Read)

-- |The abstract data structure to represent an IPv6 address.
data IPv6 = IPv6 !Word64 !Word64
deriving (Eq, Ord, Show, Read)

resulting in strings like "IPv6 2306139568115548160 1" above. I can't
really see a use for that big number representation (other than for
debugging the library...) so why not just use your existing
show*/read* functions?

> Planned for the next release:
>
>  * Support for parsing IPv4 notation embedded in IPv6 (e.g. "::192.168.1.1")

is the result a value of type IPv4 or IPv6? For an IPv4-Compatible
address I'd expect the result to be IPv4. It might also be useful to
add a conversion function to turn an IPv4 address into an IPv4-Mapped
IPv6 address.

cheers,

Conrad.

>  * Performance optimisations - IPv6 parsing/pretty printing is quite
> slow due to zero compression (>2x speed decrease)
>
> The next release will likely be v1.0.0 as there isn't much to add. I'd
> like to keep the API stable in that version, I welcome any feedback
> regarding the API (or otherwise).
>
> Hackage: http://hackage.haskell.org/package/network-address
> GitHub: https://github.com/sebnow/haskell-network-address
>
> Regards,
> Sebastian
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>

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


Re: [Haskell] [ANNOUNCE] network-address-0.2.0

2011-09-07 Thread Conrad Parker
On 8 September 2011 10:35, Ivan Lazar Miljenovic
 wrote:
> On 8 September 2011 12:19, Conrad Parker  wrote:
>>
>> given that readAddress can parse the output of showAddress, and
>> readSubnet can parse the output of showSubnet, is there any reason not
>> to use these for the implementation of Show and Read instances?
>
> My guess is that since showAddress and readsAddress are class-based,
> there might be some defaulting issues if you use them.

well, then remove them from the class interface and just use the Read
and Show classes ...

>   Also, unless
> the constructor isn't exported, isn't it usually preferable to have
> Show and Read instances produce/use actual values directly?

sure, but the roundtripping seems fairly unambiguous here.

Conrad.

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