5:25 a.m.
Hi,
here are my experiences with gretl (1.6.5) on Leopard (Mac OS X 10.5),
on an Intel Mac:
The dmg (http://ricardo.ecn.wfu.edu/pub/gretl/gretl-1.6.5.dmg) mostly
works: I can run gretl with the ./gretl command described on
http://gretl.sourceforge.net/osx.html; however, double-clicking gives an
error saying that X11 couldn't be started or something like that.
Then I tried to build from source, so I installed the most recent fink
version (0.27.9?) and followed the steps on
http://gretl.sourceforge.net/osx.html. It didn't work, here's what went
wrong:
1) installing "dlcompat" gave me a (fink) error "no package found for
specification" (BTW, I think I configured fink to use the "unstable"
packages to get more recent versions. Could that be a problem?)
2) I proceeded anyway and then gretl's configure script complained about
missing fftw3, so I installed that under fink as well.
3) Then configure went ok, but on make I got an error with
ms_ole_open_vfs. That sounds very windows-ish to me, so I guess some
platform check failed.
Any ideas? Has anything changed since 1.6.5 that could help?
thanks,
sven
6:05 a.m.
On Mon, 26 Nov 2007, Sven Schreiber wrote:
Hi,
here are my experiences with gretl (1.6.5) on Leopard (Mac OS X 10.5), on an
Intel Mac:
The dmg (http://ricardo.ecn.wfu.edu/pub/gretl/gretl-1.6.5.dmg) mostly works:
I can run gretl with the ./gretl command described on
http://gretl.sourceforge.net/osx.html; however, double-clicking gives an
error saying that X11 couldn't be started or something like that.
Then I tried to build from source, so I installed the most recent fink
version (0.27.9?) and followed the steps on
http://gretl.sourceforge.net/osx.html. It didn't work, here's what went
wrong:
1) installing "dlcompat" gave me a (fink) error "no package found for
specification" (BTW, I think I configured fink to use the "unstable"
packages
to get more recent versions. Could that be a problem?)
2) I proceeded anyway and then gretl's configure script complained about
missing fftw3, so I installed that under fink as well.
3) Then configure went ok, but on make I got an error with ms_ole_open_vfs.
That sounds very windows-ish to me, so I guess some platform check failed.
Any ideas? Has anything changed since 1.6.5 that could help?
I believe that at some point gretl was part of the fink offering; this was
very early on, like version 1.5.0 or so. I don't know what the present
state if Fink is, but IMO the only long-term solution for OSX support is
to have one or more of the Fink guys maintain a gretl package, like Dirk
Eddelbuettel does for Debian.
Alternatively, someone suggested me to check out MacPorts
(http://www.macports.org/). Apparently, this is an OSX translation of the
"port" mechanism they use in BSD-land. One may conjecture that with
MacPorts installed, it could be possible to adapt the FreeBSD gretl
port (http://www.freebsd.org/cgi/cvsweb.cgi/ports/math/gretl/). But I'm
talking about something I really have no clue on, so be careful :-)
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
7:08 a.m.
Riccardo (Jack) Lucchetti schrieb:
I believe that at some point gretl was part of the fink offering; this
was very early on, like version 1.5.0 or so. I don't know what the
present state if Fink is, but IMO the only long-term solution for OSX
support is to have one or more of the Fink guys maintain a gretl
package, like Dirk Eddelbuettel does for Debian.
Ah yes, 1.5.0 is even listed for os 10.5 (only non-binary, and it never
made it into stable, but still...). I'm installing it now, but this
takes a while, because all the dependencies have to be compiled (no
binary fink dist for 10.5 yet it seems).
Of course I agree a Mac fink maintainer would be great... Not me
however, I am not sure how long my current involvement with the Mac
platform will last.
Alternatively, someone suggested me to check out MacPorts
(http://www.macports.org/). Apparently, this is an OSX translation of
the "port" mechanism they use in BSD-land. One may conjecture that
with MacPorts installed, it could be possible to adapt the FreeBSD
gretl port (http://www.freebsd.org/cgi/cvsweb.cgi/ports/math/gretl/).
But I'm talking about something I really have no clue on, so be
careful :-)
don't worry, I certainly won't fiddle with that...
cheers,
sven
7:59 a.m.
Sven Schreiber schrieb:
Riccardo (Jack) Lucchetti schrieb:
>
> I believe that at some point gretl was part of the fink offering;
> this was very early on, like version 1.5.0 or so. I don't know what
> the present state if Fink is, but IMO the only long-term solution for
> OSX support is to have one or more of the Fink guys maintain a gretl
> package, like Dirk Eddelbuettel does for Debian.
Ah yes, 1.5.0 is even listed for os 10.5 (only non-binary, and it
never made it into stable, but still...). I'm installing it now, but
this takes a while, because all the dependencies have to be compiled
(no binary fink dist for 10.5 yet it seems).
Well this also failed, again with some ms_ole error. Note that all the
other packages (100?) that fink compiled and installed in the meantime
worked fine.
sorry, but I'm giving up now!
-sven
8:16 a.m.
On Mon, 26 Nov 2007, Sven Schreiber wrote:
here are my experiences with gretl (1.6.5) on Leopard (Mac OS X
10.5), on an Intel Mac...
1) installing "dlcompat" gave me a (fink) error "no package
found for specification" (BTW, I think I configured fink to use
the "unstable" packages to get more recent versions. Could that
be a problem?)
I suspect that dlcompat is now redundant.
2) I proceeded anyway and then gretl's configure script
complained about
missing fftw3, so I installed that under fink as well.
OK, that needs to be listed among the dependencies.
3) Then configure went ok, but on make I got an error with
ms_ole_open_vfs. That sounds very windows-ish to me, so I guess
some platform check failed.
The ms_ole stuff is part of the XLS importer, and is supposed to
be platform-independent. Could you please post the exact error
you got in that context?
I suspect that current CVS has a better chance of building on OS X
10.5 than gretl 1.6.5, though I can't think of any relevant change
in respect of ms_ole.
Allin.
8:48 a.m.
Allin Cottrell schrieb:
On Mon, 26 Nov 2007, Sven Schreiber wrote:
> 3) Then configure went ok, but on make I got an error with
> ms_ole_open_vfs. That sounds very windows-ish to me, so I guess
> some platform check failed.
>
The ms_ole stuff is part of the XLS importer, and is supposed to
be platform-independent. Could you please post the exact error
you got in that context?
(all eye-to-hand-copied from mac to pc:)
The last command in the console output is
"gcc -c <lots of parameters> .libs/ms-ole.o"
Then it says:
"../plugin/libole2/ms-ole.c: In function 'ms_ole_open_vfs':"
"../plugin/libole2/ms-ole.c:952: error: 'caddr_t' undeclared (first use
in this function)"
then a couple of other errors which I guess are triggered by the first
one, and then of course "make" giving up with an error.
I suspect that current CVS has a better chance of building on OS X
10.5 than gretl 1.6.5, though I can't think of any relevant change
in respect of ms_ole.
<puzzled> then what makes you think so? General code cleanups?
thanks,
sven
Allin.
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
9:35 a.m.
On Mon, 26 Nov 2007, Sven Schreiber wrote:
"../plugin/libole2/ms-ole.c:952: error: 'caddr_t'
undeclared
Thanks. I'm committing a change to CVS that might fix that.
This is puzzling because no such error is produced on 10.4.
> I suspect that current CVS has a better chance of building on
> OS X 10.5 than gretl 1.6.5, though I can't think of any
> relevant change in respect of ms_ole.
<puzzled> then what makes you think so? General code cleanups?
Sorry, can't be very specific, but I have built on OS X 10.4, and
have made a few changes to get things working there.
Allin.
9:49 a.m.
Allin Cottrell schrieb:
On Mon, 26 Nov 2007, Sven Schreiber wrote:
> "../plugin/libole2/ms-ole.c:952: error: 'caddr_t' undeclared
>
Thanks. I'm committing a change to CVS that might fix that.
This is puzzling because no such error is produced on 10.4.
Do you want me to try building from cvs without that patch? Don't know
what you did, but if it's just a shot in the dark it may be interesting
to see what happens without it; I mean the 1.6.5 tarball is already a
bit old, I imagine a lot has changed since then.
Anyway, maybe the compiler version in 10.5 is pickier than the one from
10.4?
-sven
10:27 a.m.
On Mon, 26 Nov 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Mon, 26 Nov 2007, Sven Schreiber wrote:
>
>
> > "../plugin/libole2/ms-ole.c:952: error: 'caddr_t' undeclared
>
> Thanks. I'm committing a change to CVS that might fix that.
> This is puzzling because no such error is produced on 10.4.
>
Do you want me to try building from cvs without that patch?
Don't know what you did, but if it's just a shot in the dark it
may be interesting to see what happens without it; I mean the
1.6.5 tarball is already a bit old, I imagine a lot has changed
since then.
Yes, a lot has changed, but the ms-ole files haven't been touched
for years, until today. I've committed a change now; I'm pretty
sure that without that change you'd get the same error.
Anyway, maybe the compiler version in 10.5 is pickier than the
one from 10.4?
It's not a matter of pickiness; I think it must be a matter of
reorganization of the system header files. If "caddr_t" is
undefined any compiler is going to barf. Apparently the
definition of caddr_t must have been moved: previously it was
getting picked up, now it's not. Today's change was to explicitly
#include <sys/types.h>
in the hope of picking up the typedef.
Allin.
4:17 p.m.
Allin Cottrell schrieb:
It's not a matter of pickiness; I think it must be a matter of
reorganization of the system header files. If "caddr_t" is
undefined any compiler is going to barf. Apparently the
definition of caddr_t must have been moved: previously it was
getting picked up, now it's not. Today's change was to explicitly
#include <sys/types.h>
in the hope of picking up the typedef.
Ok, going the cvs route now -- initially I ran into another problem
trying to compile from cvs, but fortunately I still had some notes that
said for cvs compile it was necessary to add the --enable-build-doc
switch to configure. Then I got an error that "convert" couldn't be
found. AFAIK that's part of imagemagick so I am now in the process of
installing (i.e., compiling) that and all its dependencies -- this
non-binary fink thing reminds me of gentoo a lot!
So maybe the configure script should check for "convert" when also
building the docs?
Let's see what tomorrow brings!
-sven
4:53 p.m.
Sven Schreiber schrieb:
Let's see what tomorrow brings!
Well no need to wait that long -- success! Haven't tested much, but the
gretl built from cvs at least starts up by typing gretl_x11. (this is
before doing "make install" -- Interesting that the version string is
now 1.6.6...)
thanks,
sven
5:34 p.m.
On Mon, 26 Nov 2007, Sven Schreiber wrote:
Sven Schreiber schrieb:
>
>
> Let's see what tomorrow brings!
>
Well no need to wait that long -- success! Haven't tested much,
but the gretl built from cvs at least starts up by typing
gretl_x11. (this is before doing "make install" --
That's good to hear!
Interesting that the version string is now 1.6.6...)
I was hoping to publish a release today. That may be a little
over-optimistic, but maybe tomorrow -- unless anyone's aware of
any show-stoppers.
Allin.
6:02 p.m.
On Mon, 26 Nov 2007, Allin Cottrell wrote:
On Mon, 26 Nov 2007, Sven Schreiber wrote:
> Well no need to wait that long -- success! Haven't tested much,
> but the gretl built from cvs at least starts up by typing
> gretl_x11. (this is before doing "make install" --
That's good to hear!
Well done Sven. While you're at it, you may even package a nice dmg
file... just kidding :-)
> Interesting that the version string is now 1.6.6...)
I was hoping to publish a release today. That may be a little
over-optimistic, but maybe tomorrow -- unless anyone's aware of
any show-stoppers.
Not exactly a show-stopper here, but in order to get ready for release
I've been trying random stuff and I've found we have a slight problem with
the ML Heckit estimator; try this:
<script>
open mroz87
list X = const RPWG FAMINC
heckit WW X ; LFP X
</script>
You should get gibberish for the standard errors. The reason for this is
that we rely on numerical compuatation of the Hessian for the heckit
model, and it so happens that the FAMINC variable has a scale such that
its coefficient is very small. When we compute the numerical Hessian, hell
breaks loose. If you rescale FAMINC as, say, FAMINC/1000, everything works
ok. The way I see it, we have several alternatives here:
(a) pretend nothing's wrong (no time needed :-))
(b) mention the issue in the manual and work on this after release (1 day)
(c) do some rescaling magic in heckit.c (1/2 days)
(d) refine numerical_hessian in nls.c (2/4 days including testing)
(e) provide analytical derivatives for the Heckit model (???)
Considering it's been a long time since the last release, my personal
preference goes to (c), although (d) is probably more beneficial in the
long term (of course (e) is the best, but (d) will need to be addressed
anyway sooner or later); anyway, (b) would be acceptable too. What do you
guys think?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
10 p.m.
On Tue, 27 Nov 2007, Riccardo (Jack) Lucchetti wrote:
Well done Sven. While you're at it, you may even package a nice
dmg file...
just kidding :-)
> > Interesting that the version string is now 1.6.6...)
>
> I was hoping to publish a release today. That may be a little
> over-optimistic, but maybe tomorrow -- unless anyone's aware of
> any show-stoppers.
Not exactly a show-stopper here, but in order to get ready for
release I've been trying random stuff and I've found we have a
slight problem with the ML Heckit estimator...
I'll be travelling for 10 days or so, leaving the day after
tomorrow. So for me it's a question of release what we have
tomorrow or release in a couple of weeks.
I'm open as to which we do. On the one hand it's a long time
since the last release and we've accumulated a large number of
bug-fixes; on the other, this is a point in the academic year when
people are not likely to be starting things, and looking for a
shiny new gretl release. Thoughts?
Allin.
3:31 a.m.
El Tuesday 27 November 2007 04:00:56 Allin Cottrell escribió:
I'll be travelling for 10 days or so, leaving the day after
tomorrow. So for me it's a question of release what we have
tomorrow or release in a couple of weeks.
I'm open as to which we do. On the one hand it's a long time
since the last release and we've accumulated a large number of
bug-fixes; on the other, this is a point in the academic year when
people are not likely to be starting things, and looking for a
shiny new gretl release. Thoughts?
I also think it's a long time since last release. In particular here in Bilbao
there are people waiting ansiously for the new official version (It will be
the first official version fully translated to Basque).
BTW don't you think that with all these bug-fixes and new advanced features it
deserve to be numbered 1.7 (or even 2.0, since it is completely different
from 1.0)?
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
4:16 a.m.
On Tue, 27 Nov 2007, Ignacio Diaz-Emparanza wrote:
El Tuesday 27 November 2007 04:00:56 Allin Cottrell escribió:
>
> I'll be travelling for 10 days or so, leaving the day after
> tomorrow. So for me it's a question of release what we have
> tomorrow or release in a couple of weeks.
>
> I'm open as to which we do. On the one hand it's a long time
> since the last release and we've accumulated a large number of
> bug-fixes; on the other, this is a point in the academic year when
> people are not likely to be starting things, and looking for a
> shiny new gretl release. Thoughts?
>
I also think it's a long time since last release. In particular here in Bilbao
there are people waiting ansiously for the new official version (It will be
the first official version fully translated to Basque).
BTW don't you think that with all these bug-fixes and new advanced features it
deserve to be numbered 1.7 (or even 2.0, since it is completely different
from 1.0)?
As long as the only pending issue is the Heckit thing, I'm ok with
releasing now. I've just committed a tiny addition to the help xml files
for the "heckit" command, in English and Italian. If my Spanish had been
up to par, I'd have saved Ignacio the work, but I'm sorry I don't feel
confident enough.
As for the version number, 1.7 may well be warranted IMO. On the other
hand, major version number changes are usually associated with backward
incompatibilities in the library; not that libgretl is very much used
outside of gretl itself (that I know of), but I still think it's nicer to
follow established conventions.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
6:44 a.m.
Riccardo (Jack) Lucchetti schrieb:
As long as the only pending issue is the Heckit thing, I'm ok with
releasing now. I've just committed a tiny addition to the help xml
files for the "heckit" command, in English and Italian.
I also think that
it's better to not have last-minute changes (my
mantra...).
As for the version number, 1.7 may well be warranted IMO. On the other
hand, major version number changes are usually associated with
backward incompatibilities in the library; not that libgretl is very
much used outside of gretl itself (that I know of), but I still think
it's nicer to follow established conventions.
I agree with 1.7 more than with
1.6.6 -- but ultimately I care more
about the release as such than about its number.
Thanks and have a good trip Allin,
Sven
1:04 p.m.
Looks like we have a motion to release.
I think that 1.7.0 makes sense.
I'll have to do another OS X (intel) build this evening, then I'll
put things up on sourceforge.
Allin.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
1:07 p.m.
On Tue, 27 Nov 2007, Allin Cottrell wrote:
Looks like we have a motion to release.
I think that 1.7.0 makes sense.
I'll have to do another OS X (intel) build this evening, then I'll
put things up on sourceforge.
Cheers!
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
1:12 p.m.
Allin Cottrell schrieb:
Looks like we have a motion to release.
I think that 1.7.0 makes sense.
I'll have to do another OS X (intel) build this evening, then I'll
put things up on sourceforge.
Allin.
Sounds very good!
About the version number: are there any hardcoded references to 1.6.6 in
the docs or such that should be updated? (I could help searching if you
like.)
-sven
8:18 p.m.
On Tue, 27 Nov 2007, Sven Schreiber wrote:
About the version number: are there any hardcoded references to
1.6.6 in the docs or such that should be updated? (I could help
searching if you like.)
Thanks, Sven, but I think we've avoided such hard-coded things.
(Now I'll be proved wrong!)
I've now sent 1.7.0 to sourceforge.
Allin.
6:17 a.m.
Allin Cottrell schrieb:
I've now sent 1.7.0 to sourceforge.
Thanks a lot Allin. It seems to be running fine on Windows so far.
I also hope it's not too late for Ubuntu, the release schedule page says
(http://www.ubuntugeek.com/ubuntu-804-hardy-heron-release-dates.html)
that "December 13th - DebianImportFreeze ,Remaining upstream merges
completed, Rebuild Test". I think it's good to have a new release for a
new Ubuntu version.
cheers,
sven
8:23 p.m.
On Tue, 27 Nov 2007, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
>
> Well done Sven. While you're at it, you may even package a
> nice dmg file... just kidding :-)
>
Well in the medium term I'd be glad to help by doing that if
it's useful. Any pointers to tutorials or documentation on
producing a dmg?
I can send my own notes when I get home again. Are you building
on PPC or Intel? I'm OK for building a Intel .dmg; I just can't
do PPC any more.
The ideal would be to build a "Universal binary" (PPC/Intel), but
I'm afraid I can't help with that; I have't figured out whether
you can do that using the GNU-familiar command-line tools, as I
do, or whether you have to get everything into Xcode somehow.
Allin.
4:36 a.m.
Allin Cottrell schrieb:
I can send my own notes when I get home again. Are you building
on PPC or Intel? I'm OK for building a Intel .dmg; I just can't
do PPC any more.
The ideal would be to build a "Universal binary" (PPC/Intel), but
I'm afraid I can't help with that; I have't figured out whether
you can do that using the GNU-familiar command-line tools, as I
do, or whether you have to get everything into Xcode somehow.
Right now I have a new (=>Intel) Mac Mini (with 10.5), but probably only
for the next couple of months. This would be for trying to build a
Universal Binary.
Then I have a very old PPC Powermac. I want to install OS X on that
(10.4), but it's not so easy to get hold of older install discs that
would work with it. Once I manage to actually install an osx system
there, building a ppc version is no problem. Actually I think that
having a physical ppc machine is not crucial because one could set up a
virtual ppc machine in an emulator. The problem (here in Germany at
least) is really to get an older ppc osx version at a reasonable price.
But I'm working on that.
In general I think it would be desirable to have a ppc version, because
the last G5 macs were sold until last year I think. That's not too long ago.
thanks,
sven
6199
days inactive
6201
days old
24 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber