hoc-users — General discussion about HOC

Re: [hoc-users] maintenance?

[Wolfgang T. <wol...@gm...>]

On Mon, 2015-06-01 at 16:09 +0200, Jan Brosius wrote:
> Hi,
> 
> I’d like to know if Hoc is still maintained

The most recent activity I know of was three years ago, at
https://github.com/mokus0/hoc

This repository was properly migrated from the earlier ones and contains
full history.
If you want to try anything yourself, I recommend forking from there.


Wolfgang Thaller

Re: [hoc-users] maintenance?

[André P. <oz...@al...>]

Hi Jan,

Unfortunately no, it's not maintained anymore: you can see for yourself
that the code hasn't been updated in years. I think the latest update for
it may have been to work with GHC 7 (or even 6). Sorry to disappoint! If
you're interested in maintaining it, I'm very happy for others to fork it.



On Mon, Jun 1, 2015 at 7:09 AM, Jan Brosius <bro...@gm...> wrote:

> Hi,
>
> I’d like to know if Hoc is still maintained
>
> Thx,
> Jan
>
> ------------------------------------------------------------------------------
> _______________________________________________
> hoc-users mailing list
> hoc...@li...
> https://lists.sourceforge.net/lists/listinfo/hoc-users
>

[hoc-users] maintenance?

[Jan B. <bro...@gm...>]

Hi,

I’d like to know if Hoc is still maintained

Thx,
Jan

Re: [hoc-users] Problem building HOC

[Wolfgang T. <wol...@gm...>]

On 31.12.2009, at 02:01, Luke Evans wrote:

> When I first ran the configure stage of the HOC build/install (i.e. runhaskell Setup.hs configure), it complained that "At least the following dependencies are missing: parsec >=3.0).
> Indeed, cabal showed that parsec 2.x was installed, so I managed to force 3.0.1 to be installed via cabal (cabal install 'parsec > 3' --reinstall).  Listing the cabal packages now shows 3.0.1 installed.
> 
> I expected to see the complaint about the dependency on parsec > 3 go away when I re-ran the configure step, but it did not.

The "cabal install" command probably installed the library into your home directory, so you will need to install HOC there as well. To do that, pass --user to all configure commands and to the make-bindings script.
There is probably also a --global option you can pass to cabal install for parsec, but I'm not sure if it's really called --global.

Before you proceed, though, there might be more trouble with GHC 6.12.1 ahead: an incompatibility was just reported yesterday (http://code.google.com/p/hoc/issues/detail?id=23), and I probably won't be able to fix it this year ;-).
 
Cheers,

Wolfgang

[hoc-users] Problem building HOC

[Luke E. <lu...@ev...>]

I've just found HOC.  It sounds right up my street, but I'm having problems building it.

I have Snow Leopard, with the latest GHC installed (6.12.1), and the Haskell Platform as recommended.  These were installed from the pre-built installation packages (i.e. I did not build them myself). 
I have applied the necessary patch to get gcc to build 32-bit code on my 64-bit capable machine.  Regular Haskell seem to work quite happily.

When I first ran the configure stage of the HOC build/install (i.e. runhaskell Setup.hs configure), it complained that "At least the following dependencies are missing: parsec >=3.0).
Indeed, cabal showed that parsec 2.x was installed, so I managed to force 3.0.1 to be installed via cabal (cabal install 'parsec > 3' --reinstall).  Listing the cabal packages now shows 3.0.1 installed.

I expected to see the complaint about the dependency on parsec > 3 go away when I re-ran the configure step, but it did not.

I suspect there's much I have yet to learn about the way that Haskell's cabal package management works, but right now I can't get the HOC configure step to get past this issue with the parsec dependency, and I can't run the build step until I do.

Can anyone offer any clues?

Cheers

-- Luke

[hoc-users] Fwd: what to use for NULL?

[Thorsten S. <tho...@we...>]

I just discovered my error: in my code I did

panel <- _NSOpenPanel # openPanel >>= setCanChooseDirectory True

which of course let's panel end up being a () instead of an  
NSOpenPanel ()...

After fixing this, everything was fine.

In my mail to the list I deleted the important part with the intention  
not to clutter the example unneccessary... :-(

Sorry for the noise
Thorsten

Anfang der weitergeleiteten E-Mail:

> Von: Thorsten Seitz <tho...@we...>
> Datum: 30. Mai 2009 13:24:00 MESZ
> An: hoc...@li...
> Betreff: what to use for NULL?
>
> Hi,
>
> I'm just beginning to use HOC and so far I'm very happy (I did have  
> to make some adjustments to account for GHC 6.10 and a custom  
> installation location of Xcode 3).
>
> Currently I'm stuck on calling - 
> beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo 
> : because I don't know what to pass for (coid *)contextInfo. I  
> assumed that nullPtr would be correct, but I get a type error which  
> I do not understand.
>
> My code:
>
> panel <- _NSOpenPanel # openPanel
> panel #  
> beginSheetForDirectoryFileTypesModalForWindowModalDelegateDidEndSelectorContextInfo
> 	nil
> 	nil
> 	nil
> 	window
> 	modalDelegate
> 	(getSelectorForName selector)
> 	nullPtr
>
> The type error:
>
>     Couldn't match expected type `GHC.Ptr.Ptr
>                                     HOC-1.0:HOC.Base.ObjCObject'
>            against inferred type  
> `HOC-1.0:HOC.Arguments.EvilDummyForUnit'
>     When using functional dependencies to combine
>       ObjCArgument () HOC-1.0:HOC.Arguments.EvilDummyForUnit,
>         arising from the dependency `a -> b'
>         in the instance declaration at <no location info>
>       ObjCArgument () (GHC.Ptr.Ptr HOC-1.0:HOC.Base.ObjCObject),
>         arising from a use of  
> ` 
> beginSheetForDirectoryFileTypesModalForWindowModalDelegateDidEndSelectorContextInfo 
> '
>
> Any help will be greatly appreciated!
>
> Best regards
> Thorsten
>

[hoc-users] what to use for NULL?

[Thorsten S. <tho...@we...>]

Hi,

I'm just beginning to use HOC and so far I'm very happy (I did have to  
make some adjustments to account for GHC 6.10 and a custom  
installation location of Xcode 3).

Currently I'm stuck on calling - 
beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo 
: because I don't know what to pass for (coid *)contextInfo. I assumed  
that nullPtr would be correct, but I get a type error which I do not  
understand.

My code:

panel <- _NSOpenPanel # openPanel
panel #  
beginSheetForDirectoryFileTypesModalForWindowModalDelegateDidEndSelectorContextInfo
	nil
	nil
	nil
	window
	modalDelegate
	(getSelectorForName selector)
	nullPtr

The type error:

     Couldn't match expected type `GHC.Ptr.Ptr
                                     HOC-1.0:HOC.Base.ObjCObject'
            against inferred type  
`HOC-1.0:HOC.Arguments.EvilDummyForUnit'
     When using functional dependencies to combine
       ObjCArgument () HOC-1.0:HOC.Arguments.EvilDummyForUnit,
         arising from the dependency `a -> b'
         in the instance declaration at <no location info>
       ObjCArgument () (GHC.Ptr.Ptr HOC-1.0:HOC.Base.ObjCObject),
         arising from a use of  
` 
beginSheetForDirectoryFileTypesModalForWindowModalDelegateDidEndSelectorContextInfo 
'

Any help will be greatly appreciated!

Best regards
Thorsten

[hoc-users] Can mortals build the latest source?

[Lachlan O'D. <lo...@ma...>]

Hi,

I think this is still the place to ask HOC questions. I noticed that  
work has been going on in the Google Code repository to support  
Objective-C 2, and thought it would be fun to give it a try. But I  
can't figure out how to build it. I got the impression that the build  
system was changed to Cabal fairly recently. I seem to be able to  
build the HOC module itself, but I think I also need to build  
InterfaceGenerator2 as well, and use that to create the Haskell  
interfaces for the Cocoa APIs. Is that how it works?

The InterfraceGenerator2/README file says:

> This is (mostly) a rewrite of the interface generator.
>
> *) Theoretically, the new code is more maintainable and extendable.
> *) Supports separate conversion of frameworks.
>
> It is not yet integrated into the HOC build system; build it  
> manually using Cabal.

But I can't find a .cabal file there.

Lachlan.

Re: [hoc-users] NSString dataUsingEncoding not generated

[Chris E. <ch...@ei...>]

> I was playing around with HOC again, and I noticed that some methods
> aren't generated. In particular, I saw that in the class NSString the
> method dataUsingEncoding seems to be missing. Also, functions like
> "characterAtIndex" are missing. Are other users experiencing the same
> problems? Or did I do something wrong?

Some additional info: I'm on 10.5, 6.8.3, and HOC built fine. In the  
build logs, however, I'm seeing:

 > type not found: "NSStringEncoding"

The method dataUsingEncoding uses that type, so that might have  
something to do with it. I'm not sure why the type isn't found,  
because it's just an enum in NSString [1].

Any thoughts?

-chris

[1]: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html

[hoc-users] NSString dataUsingEncoding not generated

[Chris E. <ch...@ei...>]

Hey all,

I was playing around with HOC again, and I noticed that some methods  
aren't generated. In particular, I saw that in the class NSString the  
method dataUsingEncoding seems to be missing. Also, functions like  
"characterAtIndex" are missing. Are other users experiencing the same  
problems? Or did I do something wrong?

Thanks a lot,
-chris

Re: [hoc-users] NSView initWithFrame?

[Judah J. <jud...@gm...>]

On Sun, Apr 6, 2008 at 12:28 PM, Judah Jacobson
<jud...@gm...> wrote:
> On Sun, Apr 6, 2008 at 8:21 AM, Christopher St John <cks...@gm...> wrote:
>  > I see that the project has moved to Google code, but I didn't any
>  >  mailing lists there, is this list still active? I'll give it a shot...
>  >
>  >  I'm using HOC from the google code subversion repository on
>  >  OS X 10.4.11 with ghc 6.8.2. I'm running through some exercises
>  >  in the HIllegass Cocoa Programming book. I'm trying to create
>  >  a custom view that has a designated initializer like this:
>  >
>  >   - (id)initWithFrame:(NSRect)rect
>  >   {
>  >     if( self = [super initWithFrame:rect] ) {
>  >     ...
>  >     }
>  >     return self;
>  >   }
>  >
>  >  I have the class ("StetchView") implemented in Haskell, and,
>  >  with the exception of the initializer, it runs:
>  >
>  >   $(declareClass "StretchView" "NSView")
>  >
>  >   $(exportClass "StretchView" "sv_" [
>  >               InstanceVariable "path" [t| Maybe (NSBezierPath ()) |]
>  >  [| Nothing |],
>  >               InstanceMethod 'drawRect,
>  >               InstanceMethod 'initWithFrame,
>  >               InstanceMethod 'windowNibName
>  >               ])
>  >
>  >  I've got the initializer looking like this (I was trying to cut
>  >  it down to the absolute minimum):
>  >
>  >   sv_initWithFrame rect self = do
>  >                  return self
>  >
>  >  But that doesn't work, see below for what happens.
>
>  I think you need the following (untested, but I confirmed that it typechecks):
>
>
>  sv_initWithFrame rect self = do
>     initWithFrame rect (super self)
>     -- any other custom initialization code goes here
>
>  Note that this corresponds to the call to [super initWithFrame:rect]
>  in the Objective-C code you posted above.
>
>  Hope that helps,
>  -Judah
>

Sorry, I was wrong above.  The correct code would be:

sv_initWithFrame rect self = do
     self' <- fmap castObject $ initWithFrame rect (super self)
     -- Run any custom initialization on self'
    return self'


-Judah

Re: [hoc-users] NSView initWithFrame?

[Judah J. <jud...@gm...>]

On Sun, Apr 6, 2008 at 8:21 AM, Christopher St John <cks...@gm...> wrote:
> I see that the project has moved to Google code, but I didn't any
>  mailing lists there, is this list still active? I'll give it a shot...
>
>  I'm using HOC from the google code subversion repository on
>  OS X 10.4.11 with ghc 6.8.2. I'm running through some exercises
>  in the HIllegass Cocoa Programming book. I'm trying to create
>  a custom view that has a designated initializer like this:
>
>   - (id)initWithFrame:(NSRect)rect
>   {
>     if( self = [super initWithFrame:rect] ) {
>     ...
>     }
>     return self;
>   }
>
>  I have the class ("StetchView") implemented in Haskell, and,
>  with the exception of the initializer, it runs:
>
>   $(declareClass "StretchView" "NSView")
>
>   $(exportClass "StretchView" "sv_" [
>               InstanceVariable "path" [t| Maybe (NSBezierPath ()) |]
>  [| Nothing |],
>               InstanceMethod 'drawRect,
>               InstanceMethod 'initWithFrame,
>               InstanceMethod 'windowNibName
>               ])
>
>  I've got the initializer looking like this (I was trying to cut
>  it down to the absolute minimum):
>
>   sv_initWithFrame rect self = do
>                  return self
>
>  But that doesn't work, see below for what happens.

I think you need the following (untested, but I confirmed that it typechecks):

sv_initWithFrame rect self = do
    initWithFrame rect (super self)
    -- any other custom initialization code goes here

Note that this corresponds to the call to [super initWithFrame:rect]
in the Objective-C code you posted above.

Hope that helps,
-Judah

[hoc-users] NSView initWithFrame?

[Christopher St J. <cks...@gm...>]

I see that the project has moved to Google code, but I didn't any
mailing lists there, is this list still active? I'll give it a shot...

I'm using HOC from the google code subversion repository on
OS X 10.4.11 with ghc 6.8.2. I'm running through some exercises
in the HIllegass Cocoa Programming book. I'm trying to create
a custom view that has a designated initializer like this:

  - (id)initWithFrame:(NSRect)rect
  {
    if( self = [super initWithFrame:rect] ) {
    ...
    }
    return self;
  }

I have the class ("StetchView") implemented in Haskell, and,
with the exception of the initializer, it runs:

  $(declareClass "StretchView" "NSView")

  $(exportClass "StretchView" "sv_" [
              InstanceVariable "path" [t| Maybe (NSBezierPath ()) |]
[| Nothing |],
              InstanceMethod 'drawRect,
              InstanceMethod 'initWithFrame,
              InstanceMethod 'windowNibName
              ])

I've got the initializer looking like this (I was trying to cut
it down to the absolute minimum):

  sv_initWithFrame rect self = do
                 return self

But that doesn't work, see below for what happens.

Thanks for any help/hints/suggestions-to-chuck-it-all-I'm-crazy,
etc, etc.

-cks

----------8<----------8<----------8<----------

ckspb:~/distributopia/twasker cks$ make
mkdir -p build
ghc -XTemplateHaskell --make -fglasgow-exts -fth -odir build -hidir
build Main.hs -O hoctest0g
[146 of 149] Compiling StretchView      ( StretchView.hs, build/StretchView.o )
Loading package base ... linking ... done.
Loading package array-0.1.0.0 ... linking ... done.
Loading package packedstring-0.1.0.0 ... linking ... done.
Loading package containers-0.1.0.1 ... linking ... done.
Loading package pretty-1.0.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package bytestring-0.9.0.1 ... linking ... done.
Loading package mtl-1.1.0.0 ... linking ... done.
Loading package parsec-2.1.0.0 ... linking ... done.
Loading package fgl-5.4.1.1 ... linking ... done.
Loading package binary-0.4.1 ... linking ... done.
Loading package old-locale-1.0.0.0 ... linking ... done.
Loading package old-time-1.0.0.0 ... linking ... done.
Loading package filepath-1.1.0.0 ... linking ... done.
Loading package directory-1.0.0.0 ... linking ... done.
Loading package unix-2.3.0.0 ... linking ... done.
Loading package HOC-1.0 ... linking ... done.

StretchView.hs:11:2:
    Couldn't match expected type `NewlyAllocated (StretchView ())'
           against inferred type `StretchView ()'
      Expected type: ImpType_initWithFrame
                       (StretchView ()) (StretchView ())
      Inferred type: NSRect -> StretchView () -> IO (StretchView ())
    In a 'do' expression:
        result[ahnn] <- sv_initWithFrame ::
                          ImpType_initWithFrame (StretchView ())
(StretchView ())
                        arg1 self
    In the expression:
        do result[ahnn] <- sv_initWithFrame ::
                             ImpType_initWithFrame (StretchView ())
(StretchView ())
                           arg1 self
           HOC-1.0:HOC.Invocation.recordHOCEvent
             HOC-1.0:HOC.Invocation.kHOCAboutToExportResult args
           HOC-1.0:HOC.Invocation.setMarshalledRetval
             (HOC-1.0:HOC.SelectorMarshaller.selectorInfoResultRetained
                info_initWithFrame)
             ret
             result[ahnn]
make: *** [hoctest0g] Error 1



-- 
Christopher St. John
http://artofsystems.blogspot.com

[hoc-users] HOC moving to Google Code

[<oz...@al...>]

Hi all,

HOC is in the process of moving from Sourceforge to Google Code.   
Here's the new homepage URL:

   http://code.google.com/p/hoc/

The code (CVS) repository has already been moved, and its revision  
history has been properly preserved.  The webpage contents will be  
moved over later.  If you have any HOC CVS checkouts on your machine,  
please delete them and switch over to using Google Code's SVN repo  
instead.  (If you have any patches that you were intending to submit  
back to the repo, email me a diff and I'll merge them into the new  
Subversion repository.)

For now, please continue to use these mailing lists for HOC  
discussion: I'll move over the mailing lists in a little while, with  
another announcement when that's done.

Thanks!


-- 
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>

[hoc-users] HOC Users

[Scott K <tur...@ho...>]

I have spoken with a few hoc-users.  Asked what code what code they have 
written, what tools they use, how they got HOC to build...   Mine does now.  
:)

With my interest in Haskell, OS X and hence HOC, I have been pondering how 
mature this is for decent size projects and even potiential commercial 
applications.  GHC should be good.  As is OS X.  How solid is HOC?  Easy, or 
even a powerful way to make use of OS X API's.  Easy to access additional 
Cocoa API.  Do it yourself Cocoa classes or Haskell FFI if Carbon access is 
required?  Use of Haskell network protocols versus Cocoa's?

Are these questions others are interested in?  Perhaps start a series of 
code examples or a collective project to dabble in.  The XCode plugin has 
potiential.

Any interest?

_________________________________________________________________
Local listings, incredible imagery, and driving directions - all in one 
place! http://maps.live.com/?wip=69&FORM=MGAC01

[hoc-users] Impossible to write an init method or call superclass methods?

[Dan K. <da...@gm...>]

The title is just what it says.  Without a lot more understanding of
the internals of HOC, I can't write an init method because its
argument is a NewlyAllocated object and it needs to return one that
isn't.  The workaround, of course, is to have the code that creates
your object use NSObject's init method instead, and then have a method
myInit or something that does the actual work...  This would even be
perfectly fine, if there were a way to get the method to do that for
itself, but there isn't, because, as a separate issue, you can't call
superclass methods; any attempt winds up recursing instead.

None of the examples feature init methods, because all the classes
defined in Haskell in them are created in nib files.

Well, I guess this is just a bug report, I haven't really got a
question.  I can do without init methods.

-- 
Dan Knapp

[hoc-users] HOC and GHC 6.6

[Scott K <tur...@ho...>]

I was recently thrilled to checked out HOC and have it build on GHC 6.6 
successfully.  With a prior check out and under GHC 6.4 I had not managed 
this.

Well almost.  I am not sure if some of the samples are not updated or if 
there is some setup issue.

Trying the Samples the Editor and UniqSort work.

Make on Browser produces:

mkdir -p build
ghc --make -fglasgow-exts Main.hs -odir build -hidir build -O -o Browser
[1 of 3] Compiling TVUtilities      ( TVUtilities.hs, build/TVUtilities.o )

TVUtilities.hs:60:0: parse error on input `$'
make: *** [Browser] Error 1

Make on ExpressionParser produces:

mkdir -p build
ghc --make Main.hs -odir build -hidir build -O -o ExpressionParser
[2 of 3] Compiling EPController     ( EPController.hs, build/EPController.o 
)

EPController.hs:10:0: parse error on input `$'
make: *** [ExpressionParser] Error 1



Running the tests, I get:

ghc -odir build/static/objects -hidir build/static/imports \
-o TestFoundation.static  -package-conf ../inplace.conf \
-package Foundation --make TestFoundation.hs
./TestFoundation.static
Cases: 36  Tried: 36  Errors: 0  Failures: 0
ghc -dynamic -odir build/dynamic/objects -hidir build/dynamic/imports \
-o TestFoundation.dynamic -package-conf ../inplace.conf \
-package Foundation --make TestFoundation.hs
Linking TestFoundation.dynamic ...
/usr/bin/ld: can't locate file for: -lHSHUnit_dyn
collect2: ld returned 1 exit status
make: *** [TestFoundation.dynamic] Error 1

Are these all suppose to be working currently?  Any suggestions on what to 
try as a fix?

Thanks,
Scott

_________________________________________________________________
Exercise your brain! Try Flexicon. 
http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07

[hoc-users] HOC and GHC 6.6

[Scott K <tur...@ho...>]

I was recently thrilled to checked out HOC and have it build on GHC 6.6 
successfully.  With a prior check out and under GHC 6.4 I had not managed 
this.

_________________________________________________________________
Watch free concerts with Pink, Rod Stewart, Oasis and more.  Visit MSN In 
Concert today. http://music.msn.com/presents?icid=ncmsnpresentstagline

Re: [hoc-users] HOC status?

[Wolfgang T. <wol...@gm...>]

On 28-Mar-07, at 10:32 PM, Stephyn Butcher wrote:

> Dear Wolfgang,
>
> I was wondering what the status of HOC was. Is the project pretty  
> much well dead? It looks like there hasn't been any posted work on  
> it since 2004.

Not dead at all. I haven't gotten around to making any official  
release, but there have already been some minor improvements to the  
CVS version this year, and I have an almost-finished rewrite of the  
interface generator on my hard disk.

> I probably don't know enough Objective C or Haskell to be of much  
> help but I'm interested in using it. I've been doing a bit with  
> RubyCocoa over the last year (well, until school work interfered  
> with my real learning ;))

Start with GHC 6.6 or later, and check out the current source code  
from the sourceforge CVS. Then feel free to ask any questions that  
might pop up. There is a mailing list at hoc- 
us...@li...; while I'm happy to answer your questions  
myself, it's probably a good idea to have any questions and answers  
out in the open. At least, it would prevent the project from  
appearing to be dead.

Cheers,

Wolfgang

Re: [hoc-users] ghc 6.6

[Joel R. <jo...@gm...>]

Yep, inplace.conf was it! I had to change HOC.conf as well.

On Nov 12, 2006, at 10:24 PM, Wolfgang Thaller wrote:

> Does your build tree have an old inplace.conf (I'm not sure if make  
> clean properly removes that) lying around? Or some other old stuff  
> left over from an older build?
> I recently made sure that the CVS HEAD builds with ghc-6.6, so  
> everything works on my machine.

Re: [hoc-users] ghc 6.6

[Wolfgang T. <wol...@gm...>]

On 12-Nov-06, at 11:11 PM, Joel Reymont wrote:

> Has anyone tried to compile HOC with ghc 6.6?
>
> I had it complain about the dependency on base-1.0 which I removed.

Does your build tree have an old inplace.conf (I'm not sure if make  
clean properly removes that) lying around? Or some other old stuff  
left over from an older build?
I recently made sure that the CVS HEAD builds with ghc-6.6, so  
everything works on my machine.

Cheers,
	Wolfgang

[hoc-users] ghc 6.6

[Joel R. <jo...@gm...>]

Has anyone tried to compile HOC with ghc 6.6?

I had it complain about the dependency on base-1.0 which I removed.

Now I get:

ghc-6.6:
build/objects/HOC/Base.o: unknown symbol `_autoreleaseObject'

Any ideas?

	Thanks, Joel

Re: [hoc-users] libtool -static

[Joel R. <jo...@gm...>]

On Nov 12, 2006, at 9:59 PM, Wolfgang Thaller wrote:

> Not seeing anything like that right now. The -static flag is one of  
> the two standard arguments to libtool (the other is -dynamic) and  
> therefore shouldn't be a problem --- what does it say when it  
> complains?

This is a silly issue. I had GNU libtool installed as part of  
Darwinports.

I edited the Makefile to use /usr/bin/libtool, maybe a worthy change  
to commit.

Re: [hoc-users] Information on how to build a custom NSView subclass

[Wolfgang T. <wol...@gm...>]

On 11/11/06, David Christensen <dw...@dw...> wrote:

> Of particular note, I believe that I had to export the info_drawRect
> in the $(exportClass) directive in order for the Cocoa system to be
> able to call the haskellized replacement function.

That used to be the case, now you need to use 'drawRect instead of  
info_drawRect.

On 12-Nov-06, at 1:39 AM, Joe Jones wrote:

> 1) (Serious newbie q) What does the # stand for? I haven't seen that
> yet in what I have read.

The # operator is defined by HOC as follows:

object # message = message object

A selector in HOC is just a function that takes the target object as  
its *last* argument, and # is just a way to make things look more  
object-oriented.

> 2) For the general audience: Is there any way to make the getIvar code
> (obj #. var = obj # getIVar var) disappear? This appears in every
> class and seems like something that could be part of a base class, or
> part of the template definition (note that I have no idea how the
> template stuff works so...).

David already answered this; a related question: should this  
convenience function be included in the HOC library itself?

Currently, the "official" HOC way to access instance variables are  
the getIVar and setIVar functions. The #. operator is shorter, but  
breaks the symmetry between getIVar and setIVar.

> 3) In general are all of the NSXxxx functions in
> Cocoa/Foundation/AppKit prefaced with nsXxxx in Haskell?

In general, yes. It is always possible that the HOC interface  
generator failed to parse a function declaration in Apple's header  
files and therefore left it out altogeter. Should that have happened  
to a function that you need, give me a shout on the mailing list.

On 12-Nov-06, at 3:09 AM, Joe Jones wrote:

> OK, I had to remove the NSView. prefix from the bounds call to get
> that line to compile. However, the next line tells me that :
>
>      EPView.hs:20:30: Not in scope: `set'

Again, David already answered this, but this is what you get when I  
start writing an answer, then go do something else before finishing  
it. I would hate to have to throw it away, though:

First, as a newcomer to Haskell, make sure you understand about  
Haskell's module system. Read up on import, import qualified, import  
qualified A as B etc.
There are many methods by the name "set" in Cocoa. Not all of them  
have the same type signature, so they cannot be represented by just  
one function definition in HOC. When there are several different  
selectors by the same name, none of the selectors is exported by the  
top-level module Cocoa. We have to use the module system to  
disambiguate between the different "meanings" of the word "set" in  
Cocoa.
For example, Cocoa defines:
+ (id) set;
in class NSSet, and:
- (void) set;
in class NSColor.
So, the word "set" could refer to either of those selectors, with a  
different type signature. To use them, we have to do something like  
this:

> import Cocoa
> import qualified Foundation.NSSet as NSSet
> import qualified AppKit.NSColor as NSColor
>
> ...
>
> foo myColor = do
> 	mySet <- _NSSet # NSSet.set	-- objective C: mySet = [NSSet set];
> 	myColor # NSColor.set		-- objective C: [myColor set];
> 	return mySet

Note that HOC's module names follow Cocoa's header file names, not  
Cocoa's class names.

Cheers,

Wolfgang

Re: [hoc-users] Information on how to build a custom NSView subclass

[Joe J. <dar...@gm...>]

The import worked beautifully. Thanks. Now, on to greater drawing goodness!

On 11/12/06, David Christensen <dw...@dw...> wrote:
> > OK, I had to remove the NSView. prefix from the bounds call to get
> > that line to compile.
>
> Did you include the import statement for NSView explicitly?  This may
> also be due to me forgetting to specify the import as qualified... :-)
>
> > However, the next line tells me that :
> >     EPView.hs:20:30: Not in scope: `set'
> > And I'm not sure why it's not in scope because set IS a method of
> > AppKit.NSColor.
>
> This is an exporting issue due to the fact that there are multiple
> classes in the Cocoa hierarchy which define a "set" selector.  In
> HOC, all selectors are of the same type; for these duplicate
> selectors there is no way to distinguish which selector you meant by
> name and type alone, so by default these are not exported.
>
> You can either import the module explicitly or import qualified to
> provide a different namespace for that selector to live:
>
> Either:
>
>  > import AppKit
>  > import qualified AppKit.NSColor as NSColor
>  > ...
>  > blackColor # NSColor.set
>
> Or:
>
>  > import AppKit
>  > import AppKit.NSColor (set)
>  > ...
>  > blackColor # set
>
> ----
> David Christensen
>