On 2009 Feb 21, at 20:47, Jonathan Cast wrote:
On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
Not showing platform-specific packages by default *might* make
package
writers more likely to develop cross-platform packages. We've heard
many times someone say, "I don't know if it works
On Sun, Feb 22, 2009 at 1:04 PM, Neil Mitchell wrote:
> 1) What packages should Hoogle search by default?
At the very least - all of the Haskell Platform. If/when it searches
more (+hackage flag?), perhaps the results could be ordered to place
the HP functions first.
> 2) What groups of package
sitting in a pub with some beer having a platform war). Martijn's
thoughts of +windows, +unix, +os is exactly right, I'm happy to let
users say "oh, please show me these packages", but there are
trade-offs in Hoogle design. If someone has some clear viewpoint on
the answers, I'd love to hear them.
Hi
I don't want to get in to a platform war (which I certainly don't have
time to engage in - plus its not nearly as much fun over email vs
sitting in a pub with some beer having a platform war). Martijn's
thoughts of +windows, +unix, +os is exactly right, I'm happy to let
users say "oh, please sh
John A. De Goes:
> I think the (valid) concern is that too many people are choosing
> platform-specific packages when there are alternatives available
> (albeit not as convenient in some cases), and this really hurts the
> Windows community because Windows is so radically different from all
> the o
Maybe because one Haskeller generally tries to help another one.
That's what what it means to be a community, no?
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 21, 2009, at 6:47 PM, Jonathan Cast wrote:
On S
On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
> I think the (valid) concern is that too many people are choosing
> platform-specific packages when there are alternatives available
> (albeit not as convenient in some cases), and this really hurts the
> Windows community because Win
I think the (valid) concern is that too many people are choosing
platform-specific packages when there are alternatives available
(albeit not as convenient in some cases), and this really hurts the
Windows community because Windows is so radically different from all
the other operating sy
On Sat, Feb 21, 2009 at 11:55 AM, Martijn van Steenbergen
wrote:
>
> How about allowing an extra search flag +windows that reveals
> windows-specific APIs? Likewise for other OS's.
>
> Being able to enable API for a specific package requires me knowing in what
> package I want to look, while an OS
Hi Neil,
Neil Mitchell wrote:
If a function isn't available on all OS's then all Hoogle would be
encouraging you to do is break compatibility and stop me from using
your software. If a function is only available on one OS you will
certainly have to deliberately choose to search for that, and it
Neil Mitchell wrote:
> Hi
>
>> 1) Show all the functions (when the number is low), but place platform
>> specific functions under separate headers: "Windows",
>> "Linux/BSD/POSIX", "OS X", etc.
>
> If a function isn't available on all OS's then all Hoogle would be
> encouraging you to do is break
> 1) Show all the functions (when the number is low), but place platform
> specific functions under separate headers: "Windows",
> "Linux/BSD/POSIX", "OS X", etc.
If a function isn't available on all OS's then all Hoogle would be
encouraging you to do is break compatibility and stop me from using
On Fri, Feb 20, 2009 at 1:17 AM, Neil Mitchell wrote:
> If a function isn't available on all OS's then all Hoogle would be
> encouraging you to do is break compatibility and stop me from using
> your software. If a function is only available on one OS you will
> certainly have to deliberately choo
On Fri, 2009-02-20 at 09:17 +, Neil Mitchell wrote:
> Hi
>
> > 1) Show all the functions (when the number is low), but place platform
> > specific functions under separate headers: "Windows",
> > "Linux/BSD/POSIX", "OS X", etc.
>
> If a function isn't available on all OS's then all Hoogle wou
Hi
> 1) Show all the functions (when the number is low), but place platform
> specific functions under separate headers: "Windows",
> "Linux/BSD/POSIX", "OS X", etc.
If a function isn't available on all OS's then all Hoogle would be
encouraging you to do is break compatibility and stop me from us
Thomas DuBuisson wrote:
2) Detect the OS (when possible - perhaps difficult for the web/JS
interface) and display the functions specific to the platform
requesting the search.
That kind of magic would really annoy me. I might browse on one of
several platforms, and I don't expect a search engi
On 2009 Feb 19, at 13:19, Svein Ove Aas wrote:
If you say so, but..
Unix domain sockets?
sendFd?
I can't speak to sendFd, but BITD OS/2 had AF_LOCAL (the portable
version of AF_UNIX; same API) sockets. There's no particular reason
aside from unwillingness that Windows wouldn't support it
2009/2/19 Bryan O'Sullivan :
> On Wed, Feb 18, 2009 at 6:50 PM, Thomas DuBuisson
> wrote:
>>
>> I recall that Niel made sure hoogle doesn't search through
>> non-portable libraries (a shame), but I thought Network.Socket could
>> be used on Windows and yet Hoogle does not give any results for
>> '
On Wed, Feb 18, 2009 at 6:50 PM, Thomas DuBuisson <
thomas.dubuis...@gmail.com> wrote:
> I recall that Niel made sure hoogle doesn't search through
> non-portable libraries (a shame), but I thought Network.Socket could
> be used on Windows and yet Hoogle does not give any results for
> 'socket' or
Niel,
Outside of flags to enable display of modules specific to each major
platform (+windows, +posix, +osx) I see two options. This all depends
on hoogle having some sort of list of modules for each platform, which
I believe would be the main problem.
1) Show all the functions (when the number
Hi
http://haskell.org/hoogle/?q=socket+%2Bnetwork
By default it searches the libraries supplied with Windows apart from
Network (for various technical reasons). If you add +network it will
then search the network library.
What libraries should Hoogle search by default? What flags should be
avail
The Network.Socket module works fine on Windows. The original Winsock
implementation was based on the Berkeley sockets api.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, Feb 19, 2009 at 3:50 AM, Thomas DuBuisson
wrote:
> I recall that Niel made sure hoogle doesn't search through
> non-portable libraries (a shame), but I thought Network.Socket could
> be used on Windows and yet Hoogle does not give any results for
> 'socket' or any other functions within Ne
I recall that Niel made sure hoogle doesn't search through
non-portable libraries (a shame), but I thought Network.Socket could
be used on Windows and yet Hoogle does not give any results for
'socket' or any other functions within Network.Socket.
First, am I mistaken and Network.Socket is POSIX on
24 matches
Mail list logo
