Menu
▾
▴
hoc-devel — Developer discussion about HOC
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(5) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
(18) |
Sep
(8) |
Oct
(5) |
Nov
(1) |
Dec
(14) |
| 2009 |
Jan
(9) |
Feb
(7) |
Mar
(6) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(23) |
Sep
(9) |
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(2) |
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <cod...@go...> - 2009-09-27 10:10:22
|
Comment #1 on issue 22 by wolfgang...@gmx.net: HOC does not build under Snow Leopard http://code.google.com/p/hoc/issues/detail?id=22 I haven't upgraded to Snow Leopard yet; could you attach your dist/build/HOC_cbits.o file to this issue? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-09-24 20:24:08
|
Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 22 by AntoineVanGelderJnr: HOC does not build under Snow Leopard http://code.google.com/p/hoc/issues/detail?id=22 What steps will reproduce the problem? 1. Install Haskell Platform 2.0.2 2. cabal install parsec-3.0.1 3. Fix Block.h (See http://hackage.haskell.org/trac/ghc/ticket/3522) 4. Check HOC trunk out from source control 5. cd hoc 6. cabal configure 7. cabal build What is the expected output? HOC builds. What do you see instead? pi:hoc $ cabal build Compiling HOC_cbits... HOC_cbits/MemoryManagement.m: In function ‘retainCount’: HOC_cbits/MemoryManagement.m:138: warning: cast from pointer to integer of different size Preprocessing library HOC-1.0... Preprocessing executables for HOC-1.0... Building HOC-1.0... [ 1 of 31] Compiling HOC.THDebug ( HOC/HOC/THDebug.hs, dist/build/HOC/THDebug.o ) [ 2 of 31] Compiling HOC.Unicode ( HOC/HOC/Unicode.hs, dist/build/HOC/Unicode.o ) [ 3 of 31] Compiling HOC.TH ( HOC/HOC/TH.hs, dist/build/HOC/TH.o ) [ 4 of 31] Compiling HOC.FFICallInterface ( HOC/HOC/FFICallInterface.hs, dist/build/HOC/FFICallInterface.o ) [ 5 of 31] Compiling HOC.Dyld ( HOC/HOC/Dyld.hs, dist/build/HOC/Dyld.o ) [ 6 of 31] Compiling HOC.Base ( HOC/HOC/Base.hs, dist/build/HOC/Base.o ) [ 7 of 31] Compiling HOC.Arguments ( HOC/HOC/Arguments.hs, dist/build/HOC/Arguments.o ) [ 8 of 31] Compiling HOC.ID ( HOC/HOC/ID.hs, dist/build/HOC/ID.o ) [ 9 of 31] Compiling HOC.CannedCIFs ( HOC/HOC/CannedCIFs.hs, dist/build/HOC/CannedCIFs.o ) [10 of 31] Compiling HOC.NewClass ( HOC/HOC/NewClass.hs, dist/build/HOC/NewClass.o ) [11 of 31] Compiling HOC.StdArgumentTypes ( HOC/HOC/StdArgumentTypes.hs, dist/build/HOC/StdArgumentTypes.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package parsec-3.0.1 ... linking ... done. Loading package fgl-5.4.2.2 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package HUnit-1.2.0.3 ... linking ... done. Loading object (static) dist/build/HOC_cbits.o ... ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-apple-darwin): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-09-09 17:14:15
|
Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 21 by jrvelman: hoc-read-only build problem using README instructions http://code.google.com/p/hoc/issues/detail?id=21 What steps will reproduce the problem? 1. checkout hoc-read-only from this site 2. Follow README.txt instructions up to cabal build. 3. What is the expected output? What do you see instead? Expected a build. Got instead the following error: ----------- Loading package binary-0.5.0.1 ... <command line>: can't load .so/.DLL for: HSbi nary-0.5.0.1 (dlopen(libHSbinary-0.5.0.1.dylib, 9): image not found) ----------- What version of the product are you using? On what operating system? I'm using the checked out result of svn checkout http://hoc.googlecode.com/svn/trunk/ hoc-read-only obtained on sept 8, 2009 I'm running OS X 10.5.8 on an intel iMac with Xcode is 3.1.3. Haskel and Cabal are from the Haskel platform, haskell-platform-2009.2.0.2-i386.dmg I got Parsec 3.0 from Hackage. Please provide any additional information below. Replacing every "cabal [options]" in the README.txt file with "sudo runhaskell Setup.hs [options]" resulted in apparently successful build and install. The Editor.app builds and runs. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-09-08 17:05:22
|
Updates: Status: Accepted Comment #1 on issue 20 by wolfgang...@gmx.net: Create bindings failed http://code.google.com/p/hoc/issues/detail?id=20 Oh.. I see the "cabal install" command does per-user installations by default. So for step 3, use {{{sh make-bindings-macos.sh --user}}}. I will change README.txt to suggest using "runhaskell Setup.hs" instead of the cabal command, so that the defaults for both phases match up. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-09-02 22:11:24
|
Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 20 by DexterPu: Create bindings failed http://code.google.com/p/hoc/issues/detail?id=20 What steps will reproduce the problem? 1. following README.txt to build HOC to step 2 "Create the bindings" 2. cd Bindings 3. sh make-bindings-macos.sh What is the expected output? What do you see instead? Got the following message: ~/project/os/hoc-read-only/hoc/Bindings/Generated/HOC-Foundation ~/project/os/hoc-read-only/hoc/Bindings/Generated Warning: HOC-Foundation.cabal: A package using section syntax should require "Cabal-Version: >= 1.2" or equivalent. Configuring HOC-Foundation-1.0... Setup.hs: At least the following dependencies are missing: HOC -any What version of the product are you using? On what operating system? svn head. HOC: svn head Mac OS X: 10.5.8 GHC: 6.10.4 Cabal: 1.6.0.3 Please provide any additional information below. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 23:09:49
|
Updates: Status: Fixed Comment #1 on issue 19 by wolfgang...@gmx.net: GNUstep's NSException segfaults when generating stack trace http://code.google.com/p/hoc/issues/detail?id=19 This issue was closed by revision r408. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 22:13:18
|
Issue 19: GNUstep's NSException segfaults when generating stack trace http://code.google.com/p/hoc/issues/detail?id=19 This issue is now blocking issue 17. See http://code.google.com/p/hoc/issues/detail?id=17 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 22:09:14
|
Updates: Blockedon: 19 Comment #4 on issue 17 by wolfgang...@gmx.net: GNUstep support currently broken http://code.google.com/p/hoc/issues/detail?id=17 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 22:05:06
|
Status: Accepted Owner: wolfgang...@gmx.net Labels: Type-Defect Priority-Medium OpSys-Linux Component-Core New issue 19 by wolfgang...@gmx.net: GNUstep's NSException segfaults when generating stack trace http://code.google.com/p/hoc/issues/detail?id=19 GNUstep's NSException class uses various GNU C built-in functions to generate a stack trace whenever an exception is thrown. These built-ins rely on a proper chain of %ebp-based stack frames (on i386, that is). GHC just leaves a bogus value in %ebp when it calls out from Haskell land. A segfault results. This will require either a hack to prevent GNUstep from walking the stack or a hack to "fix" the stack frame chain. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 22:01:09
|
Issue 18: GNU runtime doesn't tolerate sending messages to metaclass objects http://code.google.com/p/hoc/issues/detail?id=18 This issue is now blocking issue 17. See http://code.google.com/p/hoc/issues/detail?id=17 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 21:57:07
|
Updates: Blockedon: 18 Comment #3 on issue 17 by wolfgang...@gmx.net: GNUstep support currently broken http://code.google.com/p/hoc/issues/detail?id=17 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 21:53:04
|
Status: Accepted Owner: wolfgang...@gmx.net Labels: Type-Defect Priority-Medium OpSys-Linux Component-Core New issue 18 by wolfgang...@gmx.net: GNU runtime doesn't tolerate sending messages to metaclass objects http://code.google.com/p/hoc/issues/detail?id=18 We currently import meta-class objects to Haskell land when a class method sends a message to super. This causes at least a lookup of the __getHaskellData__ method and a call to retain. On Mac OS X, this seems to cause no problems, but the GNU runtime aborts with an assertion failure. The call to retain was introduced by enhancement issue #11 (r380, r399, merged to trunk in r402), but the __getHaskellData__ lookup was there before. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-20 10:03:02
|
Comment #2 on issue 17 by wolfgang...@gmx.net: GNUstep support currently broken http://code.google.com/p/hoc/issues/detail?id=17 Tests fail in two areas: * sending messages to super * exceptions -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-17 22:58:00
|
Comment #1 on issue 17 by wolfgang...@gmx.net: GNUstep support currently broken http://code.google.com/p/hoc/issues/detail?id=17 Cabal build now works again on GNUstep. Test suite crashes. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-17 21:44:20
|
Status: Started Owner: wolfgang...@gmx.net Labels: Type-Defect Priority-Medium OpSys-Linux New issue 17 by wolfgang...@gmx.net: GNUstep support currently broken http://code.google.com/p/hoc/issues/detail?id=17 GNUstep support has rotted on multiple levels - build system, HOC_cbits, probably the interface generator as well. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-13 15:51:32
|
james.c...@usma.edu commented on revision r402 in project hoc. Details are at http://code.google.com/p/hoc/source/detail?r=402 General Comment: Plus one straggler patch. I had to dig around to remember what it's for; it causes ClassObject instances to be generated in the .hs-boot by the interface generator. It was needed for some spliced-in "AdditionalCode" I was working on a while back. Respond to these comments at http://code.google.com/p/hoc/source/detail?r=402 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 21:54:46
|
wolfgang...@gmx.net commented on revision r380 in project hoc. Details are at http://code.google.com/p/hoc/source/detail?r=380 Score: Positive General Comment: I like it :-) Line-by-line comments: File: /branches/objc2/hoc/HOC/HOC/ID.hs (r380) =============================================================================== Line 28: dPutWords = dPutStrLn . unwords ------------------------------------------------------------------------------- No problem here, just an idea for the future: move that to some HOC.Debug module, and add a Cabal flag to enable logging. File: /branches/objc2/hoc/HOC/HOC/NewClass.hs (r380) =============================================================================== Line 98: retainCif = getCifForSelector (undefined :: Class () -> ID () -> IO (ID ())) ------------------------------------------------------------------------------- This is wrong, the additional argument should not be declared in the CIF as it only exists in Haskell land; the function that is exported to ObjC land as the implementation for retain/release is still of type ID () -> IO (ID ()) File: /branches/objc2/hoc/HOC_cbits/MemoryManagement.m (r380) =============================================================================== Line 96: objc_msgSendSuper(super, selRetain); ------------------------------------------------------------------------------- Needs to be adapted for GNUstep. Never mind for now. Respond to these comments at http://code.google.com/p/hoc/source/detail?r=380 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 14:16:03
|
Comment #3 on issue 11 by wolfgang...@gmx.net: Do not completely override retain/release http://code.google.com/p/hoc/issues/detail?id=11 Just got around to have a first look at it yesterday, my first impression is positive. I will have another look and try my best to find something wrong with it ;-). Thanks for the effort! -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 14:08:32
|
Status: Accepted Owner: wolfgang...@gmx.net Labels: Type-Defect Priority-Low New issue 16 by wolfgang...@gmx.net: Cabal build uses ugly hacks http://code.google.com/p/hoc/issues/detail?id=16 The cabal build currently uses ugly hacks to work around limitations of Cabal. See also issue #12. The Objective-C source is built by code in Setup.hs; the resulting HOC_cbits.o file is then passed to Cabal as a "C source file". Cabal attempts to "compile" this .o file by passing it to GHC; a separate hack prevents this. Finally, HOC_cbits.o is added to all GHC command lines for compiling Haskell code, so that GHC can load the Template Haskell compile time code. Cabal feature request ticket concerning Objective-C compilation support: http://hackage.haskell.org/trac/hackage/ticket/188 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 14:03:18
|
Updates: Status: Fixed Comment #10 on issue 12 by wolfgang...@gmx.net: Can't build with cabal install http://code.google.com/p/hoc/issues/detail?id=12 Should be fixed by r388. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 14:02:23
|
james.c...@usma.edu commented on revision r399 in project hoc. Details are at http://code.google.com/p/hoc/source/detail?r=399 General Comment: Forgot to indicate in log message, this was done in the objc2 branch. Respond to these comments at http://code.google.com/p/hoc/source/detail?r=399 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 14:00:13
|
Comment #2 on issue 11 by james.c...@usma.edu: Do not completely override retain/release http://code.google.com/p/hoc/issues/detail?id=11 Finally got around to cleaning up HOC.ID.importArgument'. If someone would review this work for inclusion in the trunk, I'd appreciate it. I think that in general this change is "more correct" than what was happening before, but digging so deep into the guts of the class construction and marshalling stuff makes me a bit nervous (especially considering I don't have a GNUStep system, or even an older Mac OS to test on), so I won't push it to trunk just in case I've totally misunderstood how something was supposed to work. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-12 13:48:22
|
Updates: Status: WontFix Comment #6 on issue 14 by wolfgang...@gmx.net: HoC does not build http://code.google.com/p/hoc/issues/detail?id=14 The original issue described here, being unable to build via configure/make, won't be fixed any more because the make-based build system has been removed. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-11 21:17:26
|
Updates: Status: WontFix Comment #1 on issue 2 by wolfgang...@gmx.net: HOC installs itself in an odd place with the autoconf scripts http://code.google.com/p/hoc/issues/detail?id=2 The Makefile-based build system has been retired, so this no longer applies. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-08-11 21:13:20
|
Updates: Status: Fixed Comment #2 on issue 3 by wolfgang...@gmx.net: Retire old interface generator and autoconf build system http://code.google.com/p/hoc/issues/detail?id=3 Done as of r397. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
