hoc-devel — Developer discussion about HOC

Re: [hoc-devel] Maintainance

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

On 21/06/2008, at 3:08 PM, Andrew Robbins wrote:

> I was wondering who was in charge of maintainance of the CVS  
> repository on sf.net, and if no one is, I was wondering if I could be?

Wolfgang and I are the main admins of the sf.net HOC repository; I  
tend to take of all the boring admin stuff while he actually cranks  
out the code :)


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

[hoc-devel] Maintainance

[Andrew R. <and...@ya...>]

I was wondering who was in charge of maintainance of the CVS repository on sf.net, and if no one is, I was wondering if I could be?

Andrew Robbins


      

Re: [hoc-devel] hoc in leopard?

[<m.g...@gm...>]

On Jan 6, 2008, at 1:39 AM, Wolfgang Thaller wrote:

>
> On 4-Jan-08, at 5:54 PM, m.g...@gm... wrote:
>
>> Hi I've tried to compile the last version of HOC (from googlecode)
>> under leopard without much success. the inteface generator fail to
>> parse the header files and I haven't managed to use the code in
>> directory InterfaceGenerator2 to produce alternative haskell source
>> for the Foundation and the AppKit framework.
>>
>> Any suggestion?
>
> Work in progress. The build process is in flux at the moment.
> Currently, I use InterfaceGenerator2, which currently uses the  
> headers from /Developer/SDKs/MacOSX10.4u.sdk to avoid some new  
> complications.
>
> The current method (as of today) is:
>
> runhaskell Setup.hs configure
> runhaskell Setup.hs build
> sudo runhaskell Setup.hs install
> cd Bindings
> sudo bash make-bindings-macos.sh
>
> The makefiles in Samples/ are probably outdated, so you might have  
> to tweak them (I hope I'll get to that soon).
>
> Cheers,
>
> Wolfgang
>


Thanks when I pulled the sources the cabal file and the building  
scripts were not there.
However the build command fails in the compilation of the C bits due  
to missing header ffi.h. I hacked the Setup.hs file to explicitly  
mention -I/usr/include/ffi when calling the C compiler and it worked  
fine.

hocwrap still do not work but I think I will wait until everything  
settle down.

nice work.

what are the current plans for this project?

Best,
Massimiliano

Re: [hoc-devel] hoc in leopard?

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

On 4-Jan-08, at 5:54 PM, m.g...@gm... wrote:

> Hi I've tried to compile the last version of HOC (from googlecode)
> under leopard without much success. the inteface generator fail to
> parse the header files and I haven't managed to use the code in
> directory InterfaceGenerator2 to produce alternative haskell source
> for the Foundation and the AppKit framework.
>
> Any suggestion?

Work in progress. The build process is in flux at the moment.
Currently, I use InterfaceGenerator2, which currently uses the headers  
from /Developer/SDKs/MacOSX10.4u.sdk to avoid some new complications.

The current method (as of today) is:

runhaskell Setup.hs configure
runhaskell Setup.hs build
sudo runhaskell Setup.hs install
cd Bindings
sudo bash make-bindings-macos.sh

The makefiles in Samples/ are probably outdated, so you might have to  
tweak them (I hope I'll get to that soon).

Cheers,

Wolfgang

[hoc-devel] hoc in leopard?

[<m.g...@gm...>]

Hi I've tried to compile the last version of HOC (from googlecode)  
under leopard without much success. the inteface generator fail to  
parse the header files and I haven't managed to use the code in  
directory InterfaceGenerator2 to produce alternative haskell source  
for the Foundation and the AppKit framework.

Any suggestion?

best,
Massimiliano Gubinelli

[hoc-devel] 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/>

Re: [hoc-devel] Cocoa methods not implemented in hoc

[Ruben Z. <rzi...@ya...>]

I spoke too soon. I have discovered the cause of these errors now  
after reading through the documentation more closely. Sorry about the  
false alarm.

Regards,

Ruben

On 02/01/2007, at 5:34 PM, Ruben Zilibowitz wrote:

> I have been experimenting with hoc recently. I have run into a
> problem a couple of times where certain methods of Cocoa classes
> don't seem to be in hoc. Examples are: the "set" method of NSColor
> and the "string" method of NSTextView.
>
> Whenever I use these methods, they generate errors during compilation
> saying: "Not in scope: `string'", for instance. Is this because hoc
> is still incomplete? Were they deliberately left out of hoc?
>
> Ruben
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> hoc-devel mailing list
> hoc...@li...
> https://lists.sourceforge.net/lists/listinfo/hoc-devel

[hoc-devel] Cocoa methods not implemented in hoc

[Ruben Z. <rzi...@ya...>]

I have been experimenting with hoc recently. I have run into a  
problem a couple of times where certain methods of Cocoa classes  
don't seem to be in hoc. Examples are: the "set" method of NSColor  
and the "string" method of NSTextView.

Whenever I use these methods, they generate errors during compilation  
saying: "Not in scope: `string'", for instance. Is this because hoc  
is still incomplete? Were they deliberately left out of hoc?

Ruben

Re: [hoc-devel] cvs checkout - failed build

[Ruben Z. <rzi...@ya...>]

Ok, sorry... I've fixed my own error message. It was simply a matter  
of upgrading from ghc 6.4.1 to ghc 6.6. Note: you say in the  
CHANGES.txt file that ghc 6.4 is required to build. According to what  
I'm saying that isn't right.

Whilst the ./configure; make; make install process went alright, I  
can't build the Samples. Here is the error I got trying to build to  
ExpressionParser:

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

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

I don't know what causes the error as I don't really understand hoc  
very well at this point. Any suggestions are welcome however.

Regards,

Ruben

On 01/01/2007, at 3:42 PM, Ruben Zilibowitz wrote:

> I just checked out hoc from cvs and followed the instructions in
> BUILDING.CVS and received the following error:
>
> ./HOC/TH.hs:45:24:
>      Constructor `NameG' should have 2 arguments, but has been given 3
>      When checking the pattern: Name _ (NameG _ pkg mod)
>      In a case alternative: Name _ (NameG _ pkg mod) -> NameG ns  
> pkg mod
>      In the case expression:
>          case n of
>            Name _ (NameG _ pkg mod) -> NameG ns pkg mod
>            Name _ other -> other
> make[1]: *** [ghcmake.build-stamp] Error 1
>
> I'm not sure if this error has been reported before or not. I
> couldn't see it mentioned on the archives for this mailing list, so I
> thought I would post a question about it. Can anyone suggest a fix
> for this?
>
> Thanks,
>
> Ruben Zilibowitz
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> hoc-devel mailing list
> hoc...@li...
> https://lists.sourceforge.net/lists/listinfo/hoc-devel

[hoc-devel] cvs checkout - failed build

[Ruben Z. <rzi...@ya...>]

I just checked out hoc from cvs and followed the instructions in  
BUILDING.CVS and received the following error:

./HOC/TH.hs:45:24:
     Constructor `NameG' should have 2 arguments, but has been given 3
     When checking the pattern: Name _ (NameG _ pkg mod)
     In a case alternative: Name _ (NameG _ pkg mod) -> NameG ns pkg mod
     In the case expression:
         case n of
           Name _ (NameG _ pkg mod) -> NameG ns pkg mod
           Name _ other -> other
make[1]: *** [ghcmake.build-stamp] Error 1

I'm not sure if this error has been reported before or not. I  
couldn't see it mentioned on the archives for this mailing list, so I  
thought I would post a question about it. Can anyone suggest a fix  
for this?

Thanks,

Ruben Zilibowitz

[hoc-devel] patch for building with GNUSTEP

[Samuel B. <na...@gm...>]

I had to make these changes to compile HOC from CVS with GNUSTEP (and
the GNU runtime) on Linux. I also had to comment out the following
line in the generated AppKit/AppKit/NSMenu.hs:

$(declareRenamedSelector "validateMenuItem:" "validateMenuItem" [t|
forall t1 . ID t1 -> IO Bool |])

as well as a call to hs_free_stable_ptr (though this was due to an
omitted dynamic export in my GHC 6.4).

Re: [hoc-devel] gcc 4.0 compat?

[Matthew M. <mat...@gm...>]

> Any word on what it would take for gcc 4 compatibility?  Is this even
> a project goal?  From where the build breaks, it seems like it's in
> the hoc_cbits phase.

I've been able to get it to work using a tweak to HOC_cbits/Makefile.in:

34c34
<       ld -r -x -o HOC_cbits.o $(ALL_LOAD) libHOC_cbits.a
---
>       ld -r -x -o HOC_cbits.o -lSystemStubs $(ALL_LOAD) libHOC_cbits.a

I haven't submitted it as a patch because it should be conditional on
GCC 4, and I've never messed with autoconf.

- Matt
--
http://www.matthewmorgan.net/blog

[hoc-devel] gcc 4.0 compat?

[David C. <dw...@dw...>]

Any word on what it would take for gcc 4 compatibility?  Is this even  
a project goal?  From where the build breaks, it seems like it's in  
the hoc_cbits phase.

Regards,

David Christensen

Re: [hoc-devel] fresh CVS checkout broken?

[Matthew M. <mat...@gm...>]

> ../inplace.conf: openBinaryFile: does not exist (No such file or
> directory)

I ran into this the first time I tried to build HOC from CVS, but
looking further back in the build log revealed an earlier error.  In
other words, that error may be a cascade from something earlier, not a
real problem in itself.

FWIW, my problem had to do with using gcc 4.0 in Mac OS X Tiger (see
http://sf.net/mailarchive/forum.php?thread_id=3D8262704&forum_id=3D44522
).

Hope that helps,
- Matt
--
http://www.matthewmorgan.net/blog

[hoc-devel] fresh CVS checkout broken?

[David C. <dw...@dw...>]

Hey, I tried a fresh CVS checkout of hoc, and trying to build it  
gives build errors:

../inplace.conf: openBinaryFile: does not exist (No such file or  
directory)

I followed the BUILDING.CVS procedure for building (./autogen.sh; ./ 
configure && make && make install) and the `libffi' dir has been  
moved in the hoc project directory as `libffi-src'.

Am I doing something wrong, or is the build broken?  (And a better  
question, is my patch what broke the build?)

Thanks,

David

Re: [hoc-devel] patch to add NSRange support

[Matthew M. <mat...@gm...>]

> You will be forever remembered as the first HOC user to contribute
> code :-).

And I'll forever remember it as the first time I contributed code to
an open-source project!

Speaking of which, here's another little patch, to get ifgen to
recognize the pointer typedefs for the usual struct types
(NSRangePointer, etc.).  This lets ifgen handle the methods of
NSAttributedString, for instance.

Bindings/binding-script.txt
64a65,69
> type NSPointPointer Foundation.NSGeometry;
> type NSSizePointer Foundation.NSGeometry;
> type NSRectPointer Foundation.NSGeometry;
> type NSRangePointer Foundation.NSRange;
>

Bindings/AdditionalCode/Foundation/NSGeometry.hs
8a9,11
> --X NSPointPointer
> --X NSRectPointer
> --X NSSizePointer
28a32,35
> type NSPointPointer =3D Ptr NSPoint
> type NSSizePointer  =3D Ptr NSSize
> type NSRectPointer  =3D Ptr NSRect
>

Bindings/AdditionalCode/Foundation/NSRange.hs
6a7
> --X NSRangePointer
18a20
> type NSRangePointer =3D Ptr NSRange


- Matt
--
http://www.matthewmorgan.net/blog

Re: [hoc-devel] patch to add NSRange support

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

> I noticed NSRange wasn't supported by HOC, so I took NSGeometry.hs as
> a model and whipped something up.

Thanks a lot for your contribution!
You will be forever remmebered as the first HOC user to contribute  
code :-).
I have comitted your patch to HOC's CVS.

Cheers,

Wolfgang

[hoc-devel] patch to add NSRange support

[Matthew M. <mat...@gm...>]

Hi all,

I noticed NSRange wasn't supported by HOC, so I took NSGeometry.hs as
a model and whipped something up.

Bindings/binding-script.txt:
62a63
> type NSRange Foundation.NSRange;

Bindings/AdditionalCode/Foundation/NSRange.hs is attached.

- Matt
--
http://www.matthewmorgan.net/blog

Re: [hoc-devel] HOC 0.8 release soon?

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

On 08/08/2005, at 2:47 AM, Wolfgang Thaller wrote:

>> Hi all!  (i.e. Wolfgang :)  I just did a little bit of tidying up  
>> on HOC, and think it'll be suitable for a 0.8 release soon.  Are  
>> there any extra features/bugfixes that should go in for 0.8?  If  
>> not, I'll send another email out in a couple of days, tag CVS, and  
>> release it.
>
> So as far as I'm concerned, go ahead with the release, global vars  
> can wait.

OK, I'll do a HOC release in the next few days then.  I think a 0.8  
release that's geared to work with GHC 6.4 is a good idea, followed  
by a 0.8.1 release that will work with GHC 6.4.1 if there are  
compatibility problems when that's released.

> Anyway, great work on the docs (and probably on the makefiles, too,  
> didn't have the time to try it out).

Cheers, great work on the actual code ;).


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

Re: [hoc-devel] HOC 0.8 release soon?

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

> Hi all!  (i.e. Wolfgang :)  I just did a little bit of tidying up  
> on HOC, and think it'll be suitable for a 0.8 release soon.  Are  
> there any extra features/bugfixes that should go in for 0.8?  If  
> not, I'll send another email out in a couple of days, tag CVS, and  
> release it.

I've started experiments on marshalling global variables (that extern  
const NSString * stuff all over the Cocoa headers), but that's not  
done yet, and I'm leaving for vacation tomorrow (going towards Quebec  
for 10 days).
I'll be back in Hamilton afterwards, but I'll still have a guest, so  
I won't be doing anything major then, either.
So as far as I'm concerned, go ahead with the release, global vars  
can wait.
The Simons are threatening a 6.4.1 within "a couple of weeks", too;  
Simon PJ mis-fixed a TH bug in the stable tree (see sourceforge,  
don't remmeber the number), that would require another workaround,  
but I hope he'll be able to really fix that before releasing. If not,  
we'de have to do a 0.8.1 with an extra workaround (I did work around  
the original 6.4 bug).
Anyway, great work on the docs (and probably on the makefiles, too,  
didn't have the time to try it out).

Cheers,

Wolfgang

[hoc-devel] HOC 0.8 release soon?

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

Hi all!  (i.e. Wolfgang :)  I just did a little bit of tidying up on  
HOC, and think it'll be suitable for a 0.8 release soon.  Are there  
any extra features/bugfixes that should go in for 0.8?  If not, I'll  
send another email out in a couple of days, tag CVS, and release it.


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

[hoc-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[hoc-devel] GHC support in Xcode

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

Hi all,

Just wanted to say I've found some time to do some hacking, and I'm 
making reasonable progress in integrating GHC with Xcode.  We'll have 
to end up writing bundle to add a PBXCompilerSpecificationGHC class 
(which implements PBXCompilerSpecification): writing a .pbcompspec file 
only passes a property list to its parent class.  This means that it's 
impossible to override things such as dependency analysis and 
precompile support using just a .pbcompspec file.

Through the wonders of the InputMethods directory, I've managed to 
hijack the PBXCompilerSpecificationGcc class to figure out what each 
method's meant to do, so now it's a simple matter of writing the 
implementation. :)  If anyone's interested in seeing the Xcode dumps, 
let me know and I'll put them up on a website.

I'll report back when I've made a bit more progress!


-- 
% Andre Pang : trust.in.love.to.save

[hoc-devel] Implicit variables for instance variables

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

(Hooray, first post to hoc-devel! :)

One idea which I think would be really nice: use implicit parameters to 
pass instance variables to methods.  So, normally you'd write something 
like this (taken from the ExpressionParser sample I just checked into 
CVS):

     obj #. var = obj # getIVar var

     -- ep_evaluate :: NSButton a
     --             -> EPController a
     --             -> IO ()
     ep_evaluate sender self = do
       expressionTextField <- self #. _expressionTextField
       expression <- expressionTextField # stringValue >>= haskellString
       ...

This is quite cumbersome, because you need to write extra statements 
just to get the instance variable from the object.  Using implicit 
variables, you could instead write:

     -- ep_evaluate :: ( ?expressionTextField :: NSTextField a )
     --             => NSButton a
     --             -> EPController a
     --             -> IO ()
     ep_evaluate sender self = do
       expression <- expressionTextField # stringValue >>= haskellString

This saves writing the #. helper function, and also saves having to 
write a statement that uses #. for each instance variable you want to 
pull out in every method.  The only problem I can see with this is that 
the Template Haskell syntax has to be extended to include implicit 
variables -- do you know how to do this?  If not, I'll have to do some 
hacking myself or ask Ian Lynagh about it.

Note that if you don't _use_ the implicit variables in the function, 
that's perfectly OK too, which is the behaviour we'd want.

     {-# OPTIONS -fglasgow-exts #-}

     module ImplicitParameterTest where

     aMethod :: ( ?instanceVariable1 :: String
                , ?instanceVariable2 :: Int )
             => IO ()
     aMethod = do
       putStrLn "hello!"

^ The above compiles perfectly.

(In Mocha, I was using the "unsafePerformIO $ newIORef ..." hack to do 
this because it's just so much more convenient than an explicit, 
monadic getIVar function, but implicit variables achieves the same goal 
and would be safer.)


-- 
% Andre Pang : trust.in.love.to.save