Re: [GHC] #1307: Warning refers to code not in the source
#1307: Warning refers to code not in the source
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: lowest|Milestone: _|_
Component: Compiler | Version: 6.7
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: Windows | Testcase:
Architecture: Unknown |
-+--
Comment (by igloo):
The warning referring to `notElem` isn't incorrect, though; it's just
specifying which cases (it thinks) aren't handled.
For example, if you compile
{{{
cap :: String -> String
cap ('_':cs) = cap cs
cap ('!':cs) = cap cs
cap "" = ""
}}}
with `-Wall` then you get the warning
{{{
Warning: Pattern match(es) are non-exhaustive
In the definition of `cap':
Patterns not matched: (GHC.Base.C# #x) : _ with #x `notElem`
['_', '!']
}}}
i.e. it is telling you that you have not handled the case (x:xs) where x
is not
one of ['_', '!'].
It does seem odd that it thinks that you have missing cases in your
function, though.
My HEAD, which claims to be 6.7.20070420, doesn't generate that warning.
--
Ticket URL:
GHC
ghc internal error
Hi, I´ve run into the following ghc 6.6 internal error: internal error: scavenge_stack: weird activation record found on stack: 46772 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ while doing some performance tests on TCP communication. Basically, the client flooded the server with connectTo-putStrLn-hClose sequences, obviously faster than the runtime system could follow. When I analysed the tcpdump data it showed some weird sequences of tcp packets as a result of the overload. While it was not a good idea of my program to do that, the program should probably still not crash. I hope you can use the above data to localize the bug as I have difficulties to reproduce it. It was a seldom event. Best regards, Frank___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
The Third International CISSE Conference
2007-04-28
Thread
The Second International Joint Conferences on Computer, Information, and Systems Sciences, and Engineering.
Dear Colleagues, If you received this email in error, please forward it to the appropriate department at your institution. If you wish to unsubscribe please follow the unsubscribe link at bottom of the email. Please do not reply to this message. If you need to contact us please email us at [EMAIL PROTECTED] * * The Third International Joint Conferences on Computer, * * Information, and Systems Sciences, and Engineering (CISSE 2007) * * * * * * * * http://www.cisse2007online.org * * * * * * * * December 3-12, 2007 Technically Co-Sponsored by: Institute of Electrical & Electronics Engineers (IEEE); University of Bridgeport - CONFERENCE OVERVIEW - CISSE 2007 provides a virtual forum for presentation and discussion of the state-of the-art research on computers, information and systems sciences and engineering. CISSE 2007 is the third conference of the CISSE series of e-conferences. CISSE is the World's first Engineering/Computing and Systems Research E-Conference. CISSE 2005 was the first high-caliber Research Conference in the world to be completely conducted online in real-time via the internet. CISSE 2005 received 255 research paper submissions and the final program included 140 accepted papers, from more than 45 countries. CISSE 2006 received 691 research paper submissions and the final program included 390 accepted papers, from more than 70 countries. The virtual conference will be conducted through the Internet using web-conferencing tools, made available by the conference. Authors will be presenting their PowerPoint, audio or video presentations using web-conferencing tools without the need for travel. Conference sessions will be broadcast to all the conference participants, where session participants can interact with the presenter during the presentation and (or) during the Q&A slot that follows the presentation. This international conference will be held entirely on-line. The accepted and presented papers will be made available and sent to the authors after the conference both on a DVD (including all papers, powerpoint presentations and audio presentations) and as a book publication. Springer, the official publisher for CISSE, published the 2005 proceedings in 2 books and the CISSE 2006 proceedings in four books. Conference participants - authors, presenters and attendees - only need an internet connection and sound available on their computers in order to be able to contribute and participate in this international ground-breaking conference. The on-line structure of this high-quality event will allow academic professionals and industry participants to contribute their work and attend world-class technical presentations based on rigorously refereed submissions, live, without the need for investing significant travel funds or time out of the office. The concept and format of CISSE is very exciting and ground-breaking. The PowerPoint presentations, final paper manuscripts and time schedule for live presentations over the web had been available for weeks prior to the start of the conference for all registrants, so that the participants can choose the presentations they want to attend and think about questions that they might want to ask. The live audio presentations were also recorded and are part of the permanent CISSE on-line archive - accessible to all registrants- which also includes all the papers, PowerPoint and audio presentations. Potential non-author conference attendees who cannot make the on-line conference dates are encouraged to register, as the entire joint conferences will be archived for future viewing. The CISSE conference audio room provides superb audio even over low speed internet connections, the ability to display PowerPoint presentations, and cross-platform compatibility (the conferencing software runs on Windows, Mac, and any other operating system that supports Java). In addition, the conferencing system allowed for an unlimited number of participants, which in turn granted us the opportunity to allow all CISSE participants to attend all presentations, as opposed to limiting the number of available seats for each session. Prospective authors are invited to submit full papers electronically in Micro
ghci 6.6 foreign import stdcall broken, panic, panic!!!!
ghci 6.6 foreign import stdcall broken, panic, panic Hello I would like to report what I think is a problem with GHCI foreign function imports of c functions declared with stdcall calling convention (1) and also with loading objects containing dll imports (2). I will attempt to log this in ghc trac. What is the problem ? -- (1) Prelude> :load htest3 [1 of 1] Compiling Main ( htest3.hs, interpreted ) During interactive linking, GHCi couldn't find the following symbol: test This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org (2) ghci -fglasgow-exts test_proxy5a.o -ltest3b test_proxy5a.o: unknown symbol `__imp__test' final link ... : linking extra libraries/objects failed detail follows ... CONCLUSSION REACHED (1) ghci handling of mangling of stdcall function names broken. (2) ghci loading of c object files dll imports name resolution broken. (1) ghci dose not correctly look for symbols decorated in the stdcall manner in the object files ie. it looks for _test when it should (according to stdcall convention) look for [EMAIL PROTECTED] stdcall symbols in object files are decorated with the number of bytes that should be popped from the stack before the function returns. (2) ghci cannot properly resolve dllimports in c object files i.e. if an object loaded by ghci (eg test_proxy, with c function test_proxy) calls functions from a dll (eg test) then that function in the object file will be decorated as this in normal course linked agains a .lib or a .a file will be resolved to _test function in the dll but ghci does not do this. ofcourse these problems go away when using ghc ... but well what's the point of ghci then? SUMMARY OF TESTS and METHODOLOGY 1) REFERENCE CASE verify that ccall works .. Create c file test1a.c and function test(int) in the file create haskell file htest1.hs with function ctest calling test check this works ok with (a) c object loaded (test1a.c, htest1.hs )-- OK, RIGHT! (b) windows dll, c is function dll export (test1b.c, htest1.hs ) -- OK, RIGHT! 3) change calling convention to stdcall (a) check loading of function from object (test3a.c, htest3.hs) -- FAIL, WRONG (b) check loading of stdcall function from dll -- FAIL, WRONG 4) try what shouldn't work (a) htest3 against object test1a, i.e. what hapens when you try loading a haskell module with foreign import stdcall against c function declared with ccall convention ghci loaded -- OK!!, WRONG, it should not have resolved the symbol and not loaded ghc called function and crashed -- given that it resolved the symbol and called the function this is expected (b) htest3 against dll htest1b.dll same result as 4a -- expected, behaviour consistent in both cases with resolving stdcall callouts (symbols test) in a manner consistent with ccalls i.e. resolving the call to c function test as a call to symbol _test rather than [EMAIL PROTECTED] as it should be according to stdcall convention yet the function is called as stdcall c function consequently ghci crashes when the ccall function returns and the stack has not been cleared of the function arguments as is required by the stdcall convention 5) Hmm, lets see what happens when we have a ccall c proxy function calling stdcall c function in dll etc? (a) test_proxy5a.o with test3b.dll ccall function calling stdcall function in dll unknown symbol __imp__test -- FAILED, WRONG dllimports are decorated with __imp__ so a stdcall dllimport to a c function test will appear as [EMAIL PROTECTED] the dll will export symbol [EMAIL PROTECTED], usually it is the function of the import library .a or .lib depending upon which linker mingw or msvc to resolve [EMAIL PROTECTED] to reference [EMAIL PROTECTED] in dll (b) test_proxy5b.o with test3b.dll, htest5.hs ccall function calling stdcall function (not declared as dllimport) LOADS OK, RUNS OK test_proxy5b imports symbol [EMAIL PROTECTED] the test3b.dll exports symbol [EMAIL PROTECTED] arguably this is correct behaviour as __imp__ decoration is an MS innovation and case (a) should be handled together with case (b). (c) whell what about test_proxy5b.o with test1b.dll i.e. c stdcall to a c function declared with ccall convention from .o object loaded by ghci should fail to resolve symbols, should crash program does niether hey this has me stumped
