[Haskell-cafe] Re: ANN: nano-hmac 0.2.0
Adam Langley agl at imperialviolet.org writes: Just a heads up; PHO has written nice bindings to much of OpenSSL: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsOpenSSL-0.3.1 Thanks for pointing it out. It looks like PHO has done some good work there. - Hitesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: nano-hmac 0.2.0
Don Stewart dons at galois.com writes: Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? Seems like a good time to consolidate, and produce a single openssl binding. It's tempting, but I would really hate to lose nano-md5 as it is today. I thought your concept was a great idea to inspire people to start small to get a feel for developing Haskell libraries. The current nano-md5 serves as a really good example. In the Ruby community there are many small libraries that do one, simple focused task. There are times when this is a virtue over libraries that try to be all encompassing. It's weird but I would have thought the Haskell community would have more embraced small libraries also since they may be more composable. - Hitesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Am Montag, 11. Februar 2008 21:44 schrieben Sie: Alfonso Acosta wrote: So type-level + parametrized-data is my vote. But don't let's spend too much time discussing the name. ;-) Fair enough. type-level + parameterized-data it is then (unless someone else has a better suggestion). I'm going to begin coding now. hang on, parametrized or parameterized? -- both seem like plausible spellings, but there's an e different between what you two said! What spelling is more common? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] question about STM and IO
Hello, I was recently looking at the STM library, and I have a question about the function unsafeIOToSTM. Can anyone explain to me what is unsafe about it, and what sort of use would be considered safe? Thanks, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: nano-hmac 0.2.0
Ok, I'll leave it up there as a separate package then. :) -- Don hitesh.jasani: Don, It's tempting, but I would really hate to lose nano-md5 as it is today. I thought your concept was a great idea to inspire people to start small to get a feel for developing Haskell libraries. The current nano-md5 serves as a really good example. In the Ruby community there are many small libraries that do one, simple focused task. There are times when this is a virtue over libraries that try to be all encompassing. It's weird but I would have thought the Haskell community would have more embraced small libraries also since they may be more composable. - Hitesh On Feb 11, 2008 4:29 PM, Don Stewart [EMAIL PROTECTED] wrote: hitesh.jasani: nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, SHA512. If you're unfamiliar with HMAC's then you may want to check out the second link below where I explain a little bit about them in a blog entry. The hackage pages mentioned that they're not running haddock 2.0, so I don't know if the docs will generate. If not, you can see the docs online at the third link below. * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.2.0 * http://www.jasani.org/2008/02/nano-hmac-020-released.html * http://docs.jasani.org/nano-hmac/0.2.0/ Any and all comments/suggestions/criticisms/fortune-cookie-proverbs are welcome. Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? Seems like a good time to consolidate, and produce a single openssl binding. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems
Hello, I get funny results when I call getSymbolicLinkStatus in ghc 6.8.2 on Ubuntu 7.10. This happens on several systems and has been confirmed by other people. Though, some people on almost the exact same system claimed to not see it at all. Here is an interactive example with ghci, note how the result changes from run to run. (Although not shown below, the values do sometimes repeat, so it is not completely random): Prelude System.Posix.Files.getSymbolicLinkStatus /etc/motd = print . System.Posix.Files.fileID 13165085651657739420 Prelude System.Posix.Files.getSymbolicLinkStatus /etc/motd = print . System.Posix.Files.fileID 13165312309966851228 Prelude System.Posix.Files.getSymbolicLinkStatus /etc/motd = print . System.Posix.Files.fileID 623410571888290073 Prelude System.Posix.Files.getSymbolicLinkStatus /etc/motd = print . System.Posix.Files.fileID 12892261005034 If I *compile* the following (with or without optimization): module Main where import System.Posix.Files main = do getSymbolicLinkStatus /etc/motd = print . fileID getSymbolicLinkStatus /etc/motd = print . fileID getSymbolicLinkStatus /etc/motd = print . fileID getSymbolicLinkStatus /etc/motd = print . fileID Then I get all 0: /tmp # ./test 0 0 0 0 I have tested the same code under GHC 6.6 and 6.4 and it works fine. Additionally, getFileStatus, seems to work fine everytime. (Unfortunately, I really need getSymbolicLinkStatus). If anyone has a work-around or fix that I can use in the next 15 hours, that would be extremely useful ;) Thanks in advance! j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Foreign.C.Types question ...
On Feb 12, 2008, at 14:24 , Galchin Vasili wrote: http://cvs.haskell.org/Hugs/pages/libraries/base/Foreign-C- Types.html .. I want to look at the actual code for these C types so that I can see how the instances of Storable for each type are coded so e.g. I can see how sizeOf/allignment are coded. I followed links from http://haskell.org to find the Hugs development wiki ( http://hackage.haskell.org/trac/hugs ) and found a browse source code link: http://darcs.haskell.org/darcsweb/darcsweb.cgi? r=hugs98;a=summary The bad news is that this returns a (very pretty...) Python error. Eep? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows, or GHC?
2008/2/12 Magnus Therning [EMAIL PROTECTED]:
The following code will on Linux print three strings each followed by a NULL
byte:
module Main where
putStr0 = putStr $ s ++ \0
main = do
putStr0 Hello
putStr0 Hello
putStr0 Hello
On Windows however it will print nothing! In order to trigger printing I
have to change the definition of putStr0 to
putStr0 = putStr (s ++ \0) hFlush stdout
Is this difference in behaviour due to a bug in GHC on Windows or just a
quirkiness of the platform?
I can't directly answer, but a way to find out would be to try the
same thing in C.
It seems to me that, while Linux implicitly flushes streams on exit,
Windows is failing to do so. So try the same output in C, with and
without fflush, and.. you'll see.
A program to do this follows for your convenience.
#include stdio.h
int main() {
int i;
for (int i=0; i3; i++)
puts(Hello\0);
//fflush(stdout);
return 0;
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about STM and IO
Thanks. Both this answer and Luke's make perfect sense. John On Feb 12, 2008 12:41 PM, Stephan Friedrichs [EMAIL PROTECTED] wrote: Hello, John Lato wrote: I was recently looking at the STM library, and I have a question about the function unsafeIOToSTM. Can anyone explain to me what is unsafe about it, and what sort of use would be considered safe? it's unsafe to perform IO inside of a transaction as it can't be undone, when rolling it back. I guess, unsafeIOToSTM has been designed in order to allow us to inject debugging output into a transaction, but you really shouldn't use it to perform real IO (like writing files, etc.). HTH - Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
2008/2/12 Uwe Hollerbach [EMAIL PROTECTED]: Well... I dunno. Looking at the source to GHC.Real, I see infinity, notANumber :: Rational infinity = 1 :% 0 notANumber = 0 :% 0 This is actually the reason I imported GHC.Real, because just plain % normalizes the rational number it creates, and that barfs very quickly when the denominator is 0. But the values themselves look perfectly reasonable... no? Ummm... I'm going to have to go with no. In particular we can't have signed infinity represented like this and maintain reasonable numeric laws: 1/0 = 1/(-0) = (-1)/0 Rationals are defined not to have a zero denomiator, so I'll bet in more than one place in Data.Ratio that assumption is made. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about STM and IO
Hello, John Lato wrote: I was recently looking at the STM library, and I have a question about the function unsafeIOToSTM. Can anyone explain to me what is unsafe about it, and what sort of use would be considered safe? it's unsafe to perform IO inside of a transaction as it can't be undone, when rolling it back. I guess, unsafeIOToSTM has been designed in order to allow us to inject debugging output into a transaction, but you really shouldn't use it to perform real IO (like writing files, etc.). HTH - Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
On Feb 12, 2008 6:12 AM, Jan-Willem Maessen [EMAIL PROTECTED] wrote: On Feb 12, 2008, at 1:50 AM, David Benbennick wrote: On Feb 11, 2008 10:18 PM, Uwe Hollerbach [EMAIL PROTECTED] wrote: If I fire up ghci, import Data.Ratio and GHC.Real, and then ask about the type of infinity, it tells me Rational, which as far as I can tell is Ratio Integer...? Yes, Rational is Ratio Integer. It might not be a good idea to import GHC.Real, since it doesn't seem to be documented at http://www.haskell.org/ghc/docs/latest/html/libraries/. If you just import Data.Ratio, and define pinf :: Integer pinf = 1 % 0 ninf :: Integer ninf = (-1) % 0 Then things fail the way you expect (basically, Data.Ratio isn't written to support infinity). But it's really odd the way the infinity from GHC.Real works. Anyone have an explanation? An educated guess here: the value in GHC.Real is designed to permit fromRational to yield the appropriate high-precision floating value for infinity (exploiting IEEE arithmetic in a simple, easily- understood way). If I'm right, it probably wasn't intended to be used as a Rational at all, nor to be exploited by user code. -Jan-Willem Maessen Well... I dunno. Looking at the source to GHC.Real, I see infinity, notANumber :: Rationalinfinity = 1 :% 0notANumber = 0 :% 0 This is actually the reason I imported GHC.Real, because just plain % normalizes the rational number it creates, and that barfs very quickly when the denominator is 0. But the values themselves look perfectly reasonable... no? Uwe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Windows, or GHC?
The following code will on Linux print three strings each followed by a NULL byte: module Main where putStr0 = putStr $ s ++ \0 main = do putStr0 Hello putStr0 Hello putStr0 Hello On Windows however it will print nothing! In order to trigger printing I have to change the definition of putStr0 to putStr0 = putStr (s ++ \0) hFlush stdout Is this difference in behaviour due to a bug in GHC on Windows or just a quirkiness of the platform? /M ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems
On Feb 12, 2008 8:38 PM, Jeremy Shaw [EMAIL PROTECTED] wrote:
I get funny results when I call getSymbolicLinkStatus in ghc 6.8.2 on
Ubuntu 7.10. This happens on several systems and has been confirmed by
other people.
Currently I'm looking at hsc2hs for this bug. On a 32 bit box here:
int main() {
struct stat st;
printf(size of structure is %d\n, sizeof(st));
printf(inode is at offset %d\n, __builtin_offsetof(struct stat, st_ino));
}
Gives:
size of structure is 88
inode is at offset 12
However, building Files.hsc gives:
fileID (FileStatus stat) =
unsafePerformIO $ withForeignPtr stat $ ((\hsc_ptr - peekByteOff hsc_ptr 88))
{-# LINE 315 Files.hsc #-}
e.g. it's reading random memory at the end of the structure. Looking
at the code from the documentation:
http://haskell.org/ghc/docs/latest/html/libraries/unix/src/System-Posix-Files.html#fileID
fileID (FileStatus stat) =
unsafePerformIO $ withForeignPtr stat $ ((\hsc_ptr - peekByteOff hsc_ptr 8))
{-# LINE 315 System/Posix/Files.hsc #-}
Seems like it might work, but that offset is too small. It appears
that it might be a 64-bit build (because the size of the stat
structure which when it gets malloced is 144), but a 64-bit build
should have larger offsets, not smaller.
You can't write your own fileID function, because FileStatus isn't
exported from Posix.Files. You can, however, write
getSymbolicLinkInode a c function (which does both the lstat and
extraction from the structure) and FFI it.
AGL
--
Adam Langley [EMAIL PROTECTED]
http://www.imperialviolet.org 650-283-9641
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
On Feb 12, 2008, at 1:50 AM, David Benbennick wrote: On Feb 11, 2008 10:18 PM, Uwe Hollerbach [EMAIL PROTECTED] wrote: If I fire up ghci, import Data.Ratio and GHC.Real, and then ask about the type of infinity, it tells me Rational, which as far as I can tell is Ratio Integer...? Yes, Rational is Ratio Integer. It might not be a good idea to import GHC.Real, since it doesn't seem to be documented at http://www.haskell.org/ghc/docs/latest/html/libraries/. If you just import Data.Ratio, and define pinf :: Integer pinf = 1 % 0 ninf :: Integer ninf = (-1) % 0 Then things fail the way you expect (basically, Data.Ratio isn't written to support infinity). But it's really odd the way the infinity from GHC.Real works. Anyone have an explanation? An educated guess here: the value in GHC.Real is designed to permit fromRational to yield the appropriate high-precision floating value for infinity (exploiting IEEE arithmetic in a simple, easily- understood way). If I'm right, it probably wasn't intended to be used as a Rational at all, nor to be exploited by user code. -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about STM and IO
On Feb 12, 2008 6:28 PM, John Lato [EMAIL PROTECTED] wrote: Hello, I was recently looking at the STM library, and I have a question about the function unsafeIOToSTM. Can anyone explain to me what is unsafe about it, and what sort of use would be considered safe? A few things. First, this will crash: atomically $ unsafeIOToStm $ atomically $ return () The implementation requires that transactions must not be nested, and this function allows you to nest transactions. Also, it's unclear what retry means in the context of arbitrary IO actions. A memory transaction is really only defined for exactly that: memory stuff. When you start talking about user I/O, network, etc. the transactional idea breaks down. So mostly the way I think of it is that it's semantically nonsense. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems
On Feb 12, 2008 10:44 PM, Adam Langley [EMAIL PROTECTED] wrote: Currently I'm looking at hsc2hs for this bug. On a 32 bit box here: hsc2hs is forgiven; if you build with #define _FILE_OFFSET_BITS 32 then the structure is 96 bytes and the 64-bit offset is, indeed, at offset 88. However, if you end up calling the wrong libc lstat (and it's tough to tell, because both lstat and lstat64 in libc call the system call lstat64, so strace can't tell you) you'll only get an 88 byte structure filled in. HsUnix.h has a wrapper around lstat for exactly this reason, however ltrace shows it calling the wrong one. -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org 650-283-9641 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Datatypes - Haskell
Richard A. O'Keefe [EMAIL PROTECTED] writes:
On the subject of data types, I've recently seen Haskell code using
data Foo ... = Foo { ... }
where I would have used newtype instead of data. When is it a good
idea to avoid newtype?
When the code was written before newtype was introduced into
the language? Also when { ... } is not a single type.
--
Jón Fairbairn [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Yitzchak Gale wrote: Ben Franksen wrote: ...and the Unimo paper[1] explains how to easily write a 'correct' ListT. Are you sure? Maybe I am missing something, but I don't see any claim that the Unimo ListT satisfies the laws any more than the old mtl ListT. ListT-Done-Right could also be defined via the Unimo framework, and then it would satisfy the monad laws. The list monad transformer implemented with Unimo (figure 13) is different from ListT m a = m [a] (figure 11 for reference). Note that I say the list monad transformer. I don't understand what's so special about ListT m does not fulfill the monad laws, it just shows that naïvely using m [a] to implement the list monad transformer is incorrect for general m . In other words, there is a big bug in Control.Monad.List and that's all there is to it. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A question about monad laws
I wrote: Floating point intentionally trades accuracy for speed, Jerzy Karczmarczuk wrote: 1. This is not a possible trade-off or not. In scientific/engineering computation there is really no choice, since you have to compute logarithms, trigonometric functions, etc., and some inaccuracy is unavoidable. Of course, one may use intervals, and other extremely costly stuff, but if the stability of the algorithms is well controlled, and in normal case it is (especially if the basic arithmetics has some extra control bits to do the rounding), th issue is far from being mortal. Agreed. That is what I meant by trade-off. And I am not trying to say at all that it is wrong to use it. Life is full of trade-offs. It used to be true - and may still be - that the engineers who implement floating point in the hardware of our CPUs would never fly on commercial airliners. Would you? 2. The story about engineering not flying commercial planes is largely anecdotical, and you know that. Repeating it here doesn't change much. I heard it from someone who personally worked with one such team of engineers about ten years ago. Would you entrust your country's nuclear arsenal to an automated system that depends on floating point arithmetic? 3. Nuclear arsenal is never really entrusted to an automated system, because of reasons much beyond the fl.point inaccuracies. Yes, of course, no one is really that stupid. Are they? On the other hand, in all those software one has to deal with probabilities, and with imprecise experimental data, so even if for God knows which purpose everything used exact algebraic numbers, or controlled transcendental extensions, the input imprecision would kill all the sense of infinitely precise computations thereupon. 4. The non-reliability of engineering software has many more important reasons, sometimes incredibly stupid, such as the confusion between metric and English units in the Mars Climate Orbiter crash... The Ariane 5 crash was the result not of the floating-point computation but of the conversion to signed 16-bit numers (from a 64bit double). Yes, high reliability is very hard. There are many factors that make it hard; floating point is undeniably one of them. Again - that doesn't mean that floating point should not be used. It is a powerful and important tool, as you say. I was once part of a software project in which people's lives might depend on there not being any bugs in my code. It was an experience that changed my life forever, and that is probably one of the factors that contributes to my interest in Haskell. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Yitzchak Gale writes: Jerzy Karczmarczuk wrote: Would you say that *no* typical floating-point software is reliable? It depends on how you define reliable. Floating point intentionally trades accuracy for speed, ... It used to be true - and may still be - that the engineers who implement floating point in the hardware of our CPUs would never fly on commercial airliners. Would you? Would you entrust your country's nuclear arsenal to an automated system that depends on floating point arithmetic? 1. This is not a possible trade-off or not. In scientific/engineering computation there is really no choice, since you have to compute logarithms, trigonometric functions, etc., and some inaccuracy is unavoidable. Of course, one may use intervals, and other extremely costly stuff, but if the stability of the algorithms is well controlled, and in normal case it is (especially if the basic arithmetics has some extra control bits to do the rounding), th issue is far from being mortal. 2. The story about engineering not flying commercial planes is largely anecdotical, and you know that. Repeating it here doesn't change much. 3. Nuclear arsenal is never really entrusted to an automated system, because of reasons much beyond the fl.point inaccuracies. On the other hand, in all those software one has to deal with probabilities, and with imprecise experimental data, so even if for God knows which purpose everything used exact algebraic numbers, or controlled transcendental extensions, the input imprecision would kill all the sense of infinitely precise computations thereupon. 4. The non-reliability of engineering software has many more important reasons, sometimes incredibly stupid, such as the confusion between metric and English units in the Mars Climate Orbiter crash... The Ariane 5 crash was the result not of the floating-point computation but of the conversion to signed 16-bit numers (from a 64bit double). 5. Of course, in the original posting case, the underlying math/logic is discrete, and has no similar inaccuracies, so the two worlds should not be confounded... Here, if some laws get broken, it is the result of bad conventions, which usually can be easily avoided. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A question about monad laws
Ben Franksen wrote: ...and the Unimo paper[1] explains how to easily write a 'correct' ListT. BTW, Unimo is an extreme case of the monad laws holding only w.r.t. the 'right' equality, i.e. in the laws m == m' is to be understood as observe_monad m == observe_monad m' (and even this '==' is of course /not/ the Eq class method but a semantic equality.) [1] http://web.cecs.pdx.edu/~cklin/papers/unimo-143.pdf Are you sure? Maybe I am missing something, but I don't see any claim that the Unimo ListT satisfies the laws any more than the old mtl ListT. It looks to me like Unimo is just an attempt to provide an easier way to create, use, and understand monads, not a change in their semantics. ListT-Done-Right could also be defined via the Unimo framework, and then it would satisfy the monad laws. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A question about monad laws
Jerzy Karczmarczuk wrote: Would you say that *no* typical floating-point software is reliable? It depends on how you define reliable. Floating point intentionally trades accuracy for speed, leaving it to the user to worry about round-off errors. It is usually not too hard to get the probability of failure somewhat low in practice, if you don't require a proof. It used to be true - and may still be - that the engineers who implement floating point in the hardware of our CPUs would never fly on commercial airliners. Would you? Would you entrust your country's nuclear arsenal to an automated system that depends on floating point arithmetic? Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
David Benbennick wrote: Some months ago I pointed out that Ratio Int (which is an Ord instance) doesn't satisfy this property. I provided a patch to fix the problem, but my bug report was closed as wontfix: http://hackage.haskell.org/trac/ghc/ticket/1517. Richard A. O'Keefe wrote: I'm not happy about that response... I am extremely grateful for this report, because now I know NEVER USE Ratio Int, it's too broken. Ian wrote, in the Trac ticket: Thanks for the patch, but I see a couple of problems: ...If you still think that this change should be made then I think that it should go through the library submissions process: http://www.haskell.org/haskellwiki/Library_submissions The wontfix resolution does not mean that the patch was rejected. It just means that there are reasons for and against it, so GHC HQ is not unilaterally implementing it without giving the community a chance to discuss the issues. I think that is an admirable attitude. If you feel that this issue is important, why not go ahead and start the process to get it adopted? Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows, or GHC?
Svein Ove Aas wrote:
A program to do this follows for your convenience.
#include stdio.h
int main() {
int i;
for (int i=0; i3; i++)
puts(Hello\0);
This will have the same effect as puts(Hello).
Maybe putchar(0) will actually output the NUL.
Zun.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell
I'm pleased to announce the first release of Leksah, an IDE for Haskell written in Haskell. Leksah is intended as a practical tool to support the Haskell development process. This is an unfinished pre-release with bugs and open ends. However, I decided to make a first announcement, hoping that Leksah may already be interesting and useful. Leksah uses GTK+ as GUI Toolkit with the gtk2hs binding. It is platform independent and should run on any platform where GTK+, gtk2hs and GHC can be installed. I have tested it on Windows and Linux. It only supports GHC. Features: * jumping to code every and anywhere * integration of cabal build * source candy * keymaps * configurable window * ... Some rudimentary documentation can be found in the doc/ subdirectory. Author and availability: Leksah is written by me and published under a GPL-2 license. Leksah can be optained via Hackage: http://hackage.haskell.org/ Darcs development repository: http://code.haskell.org/leksah Juergen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems
On Feb 12, 2008 11:04 PM, Adam Langley [EMAIL PROTECTED] wrote: structure filled in. HsUnix.h has a wrapper around lstat for exactly this reason, however ltrace shows it calling the wrong one. So (finally!) the real issue: hsc2hs has a C preprocessor prelude (utils/hsc2hs/template-hsc.h) which includes some GHC header files. As a result, hsc processes files in 64-bit mode: % cpp -I../../includes -dM template-hsc.h | grep FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 However, when building HsUnix.c (or any c file with cabal), the environment is different and it's built in 32-bit mode. Thus the lstat wrapper called the 32-bit glibc function, but the structure sizes and offsets in Files.hs (from Files.hsc) are all for 64-bit mode. The fix is not quite obvious. Probably hsc2hs should try harder not to change the environment so much. I'm not quite sure why the hsc2hs template pulls in the HsFFI header - it doesn't seem to need it. Although you can remove the #include and rebuild the unix package, I can safely say that you'll be reinstalling ghc if you do. What might work is changing hsc2hs and then rebuilding all of GHC. However, that's an overnight build so I don't know yet. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org 650-283-9641 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
