pre-built ghc 6.4.1 crashes building FPS
Folks, I downloaded and installed the pre-built ghc 6.4.1 on Windows XP and Win2k. I tried building FastPackedStrings but ghc crashes soon after starting. Any tips? I'm gonna try with a hand-built ghc but somehow doubt it will help. Thanks, Joel -- http://wagerlabs.com/
joelr1:
Folks,
I downloaded and installed the pre-built ghc 6.4.1 on Windows XP and Win2k. I tried building FastPackedStrings but ghc crashes soon after starting. Any tips?
I'm gonna try with a hand-built ghc but somehow doubt it will help.
Oh, now that's interesting. Do you have a log of where it crashes? It could be some Cabal code, or perhaps something strange in FPS that's tricking GHC. Which version of the FPS code is this? Just the one in the darcs repo? -- Don
Hello Donald, two notes on your FPS library: 1) your code include explicit references to Prelude.map, Prelude.length and other list functions inlcuded in Prelude. imho, this references will look better if you explicitily state List module: List.map, List.length and so on... 2) as i say you before, i need to sort filenames in windows fashion (case-ignoring), so if you will include case-ignoring comparision operators - i will be glad -- Best regards, Bulat mailto:bulatz@HotPOP.com
On 18.10 10:44, Bulat Ziganshin wrote:
2) as i say you before, i need to sort filenames in windows fashion (case-ignoring), so if you will include case-ignoring comparision operators - i will be glad
Case ignoring comparisons make only sense on characters - not on bytes. And fps is ignoring character set conversion issues. I think the proper way is to provide a layer on top of (and separate from) fps that does conversion into character strings where things like case make sense. - Einar Karttunen
ekarttun:
On 18.10 10:44, Bulat Ziganshin wrote:
2) as i say you before, i need to sort filenames in windows fashion (case-ignoring), so if you will include case-ignoring comparision operators - i will be glad
Case ignoring comparisons make only sense on characters - not on bytes. And fps is ignoring character set conversion issues. I think the proper way is to provide a layer on top of (and separate from) fps that does conversion into character strings where things like case make sense.
Indeed, SimonM's packed string code, which I'm currently integrating into FPS, is such a layer. -- Don
I am curious why FPS is implemented on top of ForeignPtr. ByteArray#
based implementation should be faster and more space efficient.
Cheers,
Krasimir
2005/10/18, Donald Bruce Stewart
ekarttun:
On 18.10 10:44, Bulat Ziganshin wrote:
2) as i say you before, i need to sort filenames in windows fashion (case-ignoring), so if you will include case-ignoring comparision operators - i will be glad
Case ignoring comparisons make only sense on characters - not on bytes. And fps is ignoring character set conversion issues. I think the proper way is to provide a layer on top of (and separate from) fps that does conversion into character strings where things like case make sense.
Indeed, SimonM's packed string code, which I'm currently integrating into FPS, is such a layer.
-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Tuesday 18 October 2005 11:07, Krasimir Angelov wrote:
I am curious why FPS is implemented on top of ForeignPtr. ByteArray# based implementation should be faster and more space efficient.
I think the reason is C compatibility. A number of functions in FPS use ffi-bound C code (mmap, gz (de-)compression,...). Ben
ByteArray# can be passed to C functions as well. The only problem is
with mmap which cann't be implemented with arrays. mmap returns a
pointer to the mapped file which is outside the Haskell heap.
Cheers,
Krasimir
2005/10/18, Benjamin Franksen
On Tuesday 18 October 2005 11:07, Krasimir Angelov wrote:
I am curious why FPS is implemented on top of ForeignPtr. ByteArray# based implementation should be faster and more space efficient.
I think the reason is C compatibility. A number of functions in FPS use ffi-bound C code (mmap, gz (de-)compression,...).
Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Tuesday 18 October 2005 12:12, Krasimir Angelov wrote:
ByteArray# can be passed to C functions as well. The only problem is with mmap which cann't be implemented with arrays. mmap returns a pointer to the mapped file which is outside the Haskell heap.
Wouldn't there be problems, too, with C routines that internally store the given pointer for later access? (GC moving the ByteArray# around...) Ben
Hello Donald, Tuesday, October 18, 2005, 11:47:32 AM, you wrote:
2) as i say you before, i need to sort filenames in windows fashion (case-ignoring), so if you will include case-ignoring comparision operators - i will be glad
Case ignoring comparisons make only sense on characters - not on bytes. And fps is ignoring character set conversion issues. I think the proper way is to provide a layer on top of (and separate from) fps that does conversion into character strings where things like case make sense.
DBS> Indeed, SimonM's packed string code, which I'm currently integrating DBS> into FPS, is such a layer. anyway, i need to convert Strings containing filenames to packed strings and then sort filelist on filenames ignoring case. current FPS lib don't give me such ability. and of course i don'w want to convert byte arrays back to [Char] just to compare strings -- Best regards, Bulat mailto:bulatz@HotPOP.com
Hello Donald, 4) several times you use advancePtr, which may be replaced with plusPtr in this cases. moreover, i can sell you the following mini-library for all those Ptr operations: infixl 6 +:, -: ptr+:n = ptr `plusPtr` (fromIntegral n) ptr-:buf = fromIntegral (ptr `minusPtr` buf) -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Tue, Oct 18, 2005 at 10:39:24AM +0300, Einar Karttunen wrote:
On 18.10 10:44, Bulat Ziganshin wrote:
2) as i say you before, i need to sort filenames in windows fashion (case-ignoring), so if you will include case-ignoring comparision operators - i will be glad
Case ignoring comparisons make only sense on characters - not on bytes. And fps is ignoring character set conversion issues. I think the proper way is to provide a layer on top of (and separate from) fps that does conversion into character strings where things like case make sense.
My FastString library always stores everything as UTF8 to good effect. I have some nice fast unboxed UTF8 character folding routines in there too which you might want to grab if you go the UTF8 route. (which I recommend highly). http://repetae.net/john/repos/jhc/PackedString.hs John -- John Meacham - ⑆repetae.net⑆john⑈
Just the latest darcs repo. It's a memory access error 0x0:0x0 I think (null pointer reference?) at the "setup build" stage. On Oct 18, 2005, at 2:01 AM, Donald Bruce Stewart wrote:
Oh, now that's interesting. Do you have a log of where it crashes? It could be some Cabal code, or perhaps something strange in FPS that's tricking GHC.
Which version of the FPS code is this? Just the one in the darcs repo?
Another person reports that the same happens while building HSQL. https://sourceforge.net/tracker/? func=detail&atid=108032&aid=1328684&group_id=8032 On Oct 18, 2005, at 2:01 AM, Donald Bruce Stewart wrote:
Oh, now that's interesting. Do you have a log of where it crashes? It could be some Cabal code, or perhaps something strange in FPS that's tricking GHC.
participants (7)
-
Benjamin Franksen -
Bulat Ziganshin -
dons＠cse.unsw.edu.au -
Einar Karttunen -
Joel Reymont -
John Meacham -
Krasimir Angelov