8:02 p.m.
The gretl CVS tree currently contains a "lite" version of
gtksourceview 1.8.5 (in gui2/gtksourceview).
I included this partly so that one could build gretl for
Windows and OS X without relying on an installed version of
gtksourceview. In addition, when we first introduced syntax
highlighting in gretl gtksourceview was still fairly new, and
might not have been available for all Linux distros.
But now time has moved on: I've successfully built full
gtksourceview-2.0 libraries for Windows and OS X, and it's
quite standard in Linux distros. I'm therefore thinking of (a)
removing the "bundled" gtksourceview from gretl CVS, and (b)
specifying gtksourceview-2.0 as a gretl dependency.
As regards point (b), right now our syntax highlighting code
supports both gtksourceview-1.0 and gtksourceview-2.0, but I
don't see much point in continuing to support the old version.
Version 2.0 has been available since 2007, and is required to
support printing with highlighting.
Does anyone have any objection to this?
Allin
9:12 a.m.
On 05-09-2011, at 22:02, Allin Cottrell wrote:
The gretl CVS tree currently contains a "lite" version of
gtksourceview 1.8.5 (in gui2/gtksourceview).
I included this partly so that one could build gretl for
Windows and OS X without relying on an installed version of
gtksourceview. In addition, when we first introduced syntax
highlighting in gretl gtksourceview was still fairly new, and
might not have been available for all Linux distros.
But now time has moved on: I've successfully built full
gtksourceview-2.0 libraries for Windows and OS X, and it's
quite standard in Linux distros. I'm therefore thinking of (a)
removing the "bundled" gtksourceview from gretl CVS, and (b)
specifying gtksourceview-2.0 as a gretl dependency.
As regards point (b), right now our syntax highlighting code
supports both gtksourceview-1.0 and gtksourceview-2.0, but I
don't see much point in continuing to support the old version.
Version 2.0 has been available since 2007, and is required to
support printing with highlighting.
Does anyone have any objection to this?
Not really.
I compile Gretl on the Mac using the GTK 2.14 framework (using as few .dylibs as
possible).
It would be nice if I could still do that.
So:
- which version of gtksourceview have you used for Mac OS X?
(if it's version 2.0.2 there shouldn't be any problem)
- what do I need to compile gtksourceview on the mac?
Berend
12:43 p.m.
On Tue, 6 Sep 2011, Berend Hasselman wrote:
On 05-09-2011, at 22:02, Allin Cottrell wrote:
> [...] I'm therefore thinking of (a) removing the "bundled"
> gtksourceview from gretl CVS, and (b) specifying
> gtksourceview-2.0 as a gretl dependency.
>
> Does anyone have any objection to this?
Not really.
I compile Gretl on the Mac using the GTK 2.14 framework (using as few .dylibs as
possible).
It would be nice if I could still do that.
So:
- which version of gtksourceview have you used for Mac OS X?
(if it's version 2.0.2 there shouldn't be any problem)
- what do I need to compile gtksourceview on the mac?
Good questions. For the Mac package I'm using the latest
stable gtksourceview-2.0, namely version 2.10.5. The
dependencies for building this are satisfied by what's in the
GTK 2.14 framework plus what's on OS X already (e.g. libxml2).
With one exception: there are a few lines of code that depend
on GTK 2.16, but these are not essential and I have a small
patch that fixes that.
I can easily make available in some public place (a) my patch
and/or (b) a (universal or single-architecture) package
containing the dylib and headers for gtksourceview 2.10.5.
In fact, I might as well attach the patch here in case you'd
like to try it yourself.
Allin
6:10 p.m.
On 06-09-2011, at 14:43, Allin Cottrell wrote:
On Tue, 6 Sep 2011, Berend Hasselman wrote:
> On 05-09-2011, at 22:02, Allin Cottrell wrote:
>
>> [...] I'm therefore thinking of (a) removing the "bundled"
gtksourceview from gretl CVS, and (b) specifying gtksourceview-2.0 as a gretl dependency.
>>
>> Does anyone have any objection to this?
>
> Not really.
> I compile Gretl on the Mac using the GTK 2.14 framework (using as few .dylibs as
possible).
> It would be nice if I could still do that.
> So:
> - which version of gtksourceview have you used for Mac OS X?
> (if it's version 2.0.2 there shouldn't be any problem)
> - what do I need to compile gtksourceview on the mac?
Good questions. For the Mac package I'm using the latest stable gtksourceview-2.0,
namely version 2.10.5. The dependencies for building this are satisfied by what's in
the GTK 2.14 framework plus what's on OS X already (e.g. libxml2).
With one exception: there are a few lines of code that depend on GTK 2.16, but these are
not essential and I have a small patch that fixes that.
I can easily make available in some public place (a) my patch and/or (b) a (universal or
single-architecture) package containing the dylib and headers for gtksourceview 2.10.5.
I'm quite sure that both (a) and (b) would be most welcome.
In fact, I might as well attach the patch here in case you'd like
to try it yourself.
I have applied the patch. I also needed to get intltool (version 0.40.6) which I assume
is only needed for the build phase. I've been able to build a static as well as
dynamic library of gtksourceview.
Thanks very much for this.
Berend
7:39 p.m.
On Tue, 6 Sep 2011, Berend Hasselman wrote:
On 06-09-2011, at 14:43, Allin Cottrell wrote:
> For the Mac package I'm using the latest
> stable gtksourceview-2.0, namely version 2.10.5. The
> dependencies for building this are satisfied by what's in
> the GTK 2.14 framework plus what's on OS X already (e.g.
> libxml2).
> I can easily make available in some public place (a) my
> patch and/or (b) a (universal or single-architecture)
> package containing the dylib and headers for gtksourceview
> 2.10.5.
I'm quite sure that both (a) and (b) would be most welcome.
OK, I'll find somewhere suitable to put those things.
> In fact, I might as well attach the patch here in case
> you'd like to try it yourself.
I have applied the patch. I also needed to get intltool
(version 0.40.6) which I assume is only needed for the build
phase. I've been able to build a static as well as dynamic
library of gtksourceview.
Ah, yes, that's just for the build. Glad to hear it worked for
you.
Allin
5:26 a.m.
On Mon, 5 Sep 2011, Allin Cottrell wrote:
But now time has moved on: I've successfully built full
gtksourceview-2.0 libraries for Windows and OS X, and it's
quite standard in Linux distros. I'm therefore thinking of (a)
removing the "bundled" gtksourceview from gretl CVS, and (b)
specifying gtksourceview-2.0 as a gretl dependency.
For those building gretl on Debian/Ubuntu: you may need to install the
libgtksourceview2.0-dev package (before the recent changes, it was not
required; it is now). Otherwise, your build may stop with gcc complaining
about "gtk_source_buffer_get_highlight_matching_brackets" being missing.
BTW: I guess some adjustments to configure.in are needed.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
2:09 p.m.
On Tue, 13 Sep 2011, Riccardo (Jack) Lucchetti wrote:
On Mon, 5 Sep 2011, Allin Cottrell wrote:
> But now time has moved on: I've successfully built full
> gtksourceview-2.0 libraries for Windows and OS X, and it's
> quite standard in Linux distros. I'm therefore thinking of (a)
> removing the "bundled" gtksourceview from gretl CVS, and (b)
> specifying gtksourceview-2.0 as a gretl dependency.
For those building gretl on Debian/Ubuntu: you may need to install the
libgtksourceview2.0-dev package (before the recent changes, it was not
required; it is now). Otherwise, your build may stop with gcc complaining
about "gtk_source_buffer_get_highlight_matching_brackets" being missing.
BTW: I guess some adjustments to configure.in are needed.
Sorry, we're in a slightly broken state right now, as you say.
Either we (a) fix things so that it's still possible to use
gtksourceview-1.0 (without printing support), and to use the
bundled version of gtksourceview-1.0 as a fallback, or (b)
we remove support for gtksourceview-1.0 altogether and adjust
configure.in to insist on gtksourceview-2.0.
I'm inclined towards (b), but I'd be OK with (a) for gretl
1.9.6, at least.
Allin
2:16 p.m.
On Tue, 13 Sep 2011, Allin Cottrell wrote:
On Tue, 13 Sep 2011, Riccardo (Jack) Lucchetti wrote:
> On Mon, 5 Sep 2011, Allin Cottrell wrote:
>
>> But now time has moved on: I've successfully built full
>> gtksourceview-2.0 libraries for Windows and OS X, and it's
>> quite standard in Linux distros. I'm therefore thinking of (a)
>> removing the "bundled" gtksourceview from gretl CVS, and (b)
>> specifying gtksourceview-2.0 as a gretl dependency.
>
> For those building gretl on Debian/Ubuntu: you may need to install the
> libgtksourceview2.0-dev package (before the recent changes, it was not
> required; it is now). Otherwise, your build may stop with gcc complaining
> about "gtk_source_buffer_get_highlight_matching_brackets" being missing.
>
> BTW: I guess some adjustments to configure.in are needed.
Sorry, we're in a slightly broken state right now, as you say.
Either we (a) fix things so that it's still possible to use
gtksourceview-1.0 (without printing support), and to use the
bundled version of gtksourceview-1.0 as a fallback, or (b)
we remove support for gtksourceview-1.0 altogether and adjust
configure.in to insist on gtksourceview-2.0.
I'm inclined towards (b), but I'd be OK with (a) for gretl 1.9.6, at least.
My vote goes to (b) too.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
10:53 a.m.
New subject: ARIMA output
I think there is something slightly incorrect in the second part of the
ARIMA output. Look for example to the output generated by a pure
seasonal model as the one in this script:
<hansl>
nulldata 500
setobs 4 1:1 --time-series
set seed 1234
eps=randgen(N,0,1)
Yt=0*const
Yt=0.8*Yt(-4)+eps
arma 0 0 ; 1 0 ; Yt --nc
</hansl>
with this seed I obtain here an estimated coefficient of 0.75, and the
second part of the gretl output table reports the roots as:
<output>
Real Imaginary Modulus Frequency
-----------------------------------------------------------
AR (seasonal)
Root 1 1.3223 0.0000 1.3223 0.0000
-----------------------------------------------------------
</output>
but this is not exactly correct. The estimated AR polynomial is (1-0.75
L^4) which has four roots in 1.32, -1.32, 1.32i and -1.32i, all of them
with the same modulus, 1.32, and being their frequencies 0, 0.5, and
0.25 (the two complex roots with the same observed frequency because of
the aliasing problem).
I think for the non-seasonal part it is interesting to report the roots
as we are doing now, but for the seasonal part I think that showing all
the roots and frequencies may be excessive (imagine in the weekly case,
52 roots), but for not inducing the user to something incorrect we
should report only the modulus.
--
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.ea3.ehu.es
1:32 p.m.
New subject: bundle
Umm ... It seems that the 'bundle' command is not in the gretl Command
Reference.
--
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.ea3.ehu.es
5:31 p.m.
New subject: bundle
On Thu, Sep 15, 2011 at 9:32 AM, Ignacio Diaz-Emparanza
<ignacio.diaz-emparanza(a)ehu.es> wrote:
Umm ... It seems that the 'bundle' command is not in the
gretl Command
Reference.
"bundle" is not a command,it's the name of a type, like "matrix"
or "scalar".
So far as the docs go, what we need is something that Jack has mentioned,
namely a systematic guide to hansl, which would include discussion of all
the types. The information is in the User's Guide, but not in a very
convenient form.
Allin
8:33 a.m.
New subject: bundle
El 15/09/11 19:31, Cottrell, Allin escribió:
On Thu, Sep 15, 2011 at 9:32 AM, Ignacio Diaz-Emparanza
<ignacio.diaz-emparanza(a)ehu.es> wrote:
> Umm ... It seems that the 'bundle' command is not in the gretl Command
> Reference.
"bundle" is not a command,it's the name of a type, like "matrix"
or "scalar".
So far as the docs go, what we need is something that Jack has mentioned,
namely a systematic guide to hansl, which would include discussion of all
the types. The information is in the User's Guide, but not in a very
convenient form.
Ok. I was looking for how to manage the bundle plots (for putting two
different graphs in the menu) but I did not found it in the User's Guide.
Finally I understood how to do it thanks to your explanation in
http://www.wfu.edu/~cottrell/tmp/extending.pdf
(Google helped to find it)
--
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.ea3.ehu.es
4857
days inactive
4868
days old
11 comments
5 participants
participants (5)
-
Allin Cottrell -
Berend Hasselman -
Cottrell, Allin
-
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti