11:21 p.m.
I've established a git repository for gretl on sourceforge, synced
with CVS as of this evening.
The CVS repository is still there at present as an insurance policy,
but it shouldn't be used for commits.
There's a brief "survival guide" at
http://ricardo.ecn.wfu.edu/~cottrell/gretl-git-basics.html
with info an accessing the repository and translation from cvs
commands to git ones for basic operations.
I don't suppose this needs saying, but of course feel free to ask
questions here in case of problems. One point to note is that it'll
take the sourceforge git engine a while to process all the
information just dumped on it. You're likely to see a spinner
with "Repo status: analyzing..." if you visit the web interface to
gretl git, and that might not be finished until tomorrow.
Allin
7:02 a.m.
Am 02.10.2015 um 01:21 schrieb Allin Cottrell:
I've established a git repository for gretl on sourceforge,
synced with
CVS as of this evening.
The CVS repository is still there at present as an insurance policy, but
it shouldn't be used for commits.
There's a brief "survival guide" at
http://ricardo.ecn.wfu.edu/~cottrell/gretl-git-basics.html
with info an accessing the repository and translation from cvs commands
to git ones for basic operations.
How does the logging-in work now? I used to do "ssh-add
<my_SF_keyfile>", type in my passphrase, then "export CVS_RSH=ssh",
before I commit something with cvs. I guess at least the export command
has to be changed.
thanks,
sven
10:55 a.m.
On Fri, 2 Oct 2015, Sven Schreiber wrote:
Am 02.10.2015 um 01:21 schrieb Allin Cottrell:
> I've established a git repository for gretl on sourceforge, synced with
> CVS as of this evening.
>
> The CVS repository is still there at present as an insurance policy, but
> it shouldn't be used for commits.
>
> There's a brief "survival guide" at
> http://ricardo.ecn.wfu.edu/~cottrell/gretl-git-basics.html
> with info an accessing the repository and translation from cvs commands
> to git ones for basic operations.
>
How does the logging-in work now? I used to do "ssh-add
<my_SF_keyfile>", type in my passphrase, then "export CVS_RSH=ssh",
before I commit something with cvs. I guess at least the export command
has to be changed.
I didn't have to do anything, ssh was clever enough to log me in
automatically as per usual.
Another thing that may be useful to CVS users: an operation that I would
perform very often (at least once a day, but often much more frequently
than that) was
cvs diff -uw
mainly to check what Allin had done during the night (time zones are
_so_ nice). You now simply do
git diff
since unified format is the default for git.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
11:25 a.m.
And there are a lot of good things to use with git. For example, I use the
tool meld for merging and diff files.
Look for git mergetool and git difftool commands.
Install meld from http://meldmerge.org/
Thanks Allin for the good instructions you prepared (I'll see if I could
auto login for other github projects too).
On Fri, Oct 2, 2015 at 11:55 AM, Riccardo (Jack) Lucchetti <
r.lucchetti(a)univpm.it> wrote:
On Fri, 2 Oct 2015, Sven Schreiber wrote:
> Am 02.10.2015 um 01:21 schrieb Allin Cottrell:
>
>> I've established a git repository for gretl on sourceforge, synced with
>> CVS as of this evening.
>>
>> The CVS repository is still there at present as an insurance policy, but
>> it shouldn't be used for commits.
>>
>> There's a brief "survival guide" at
>> http://ricardo.ecn.wfu.edu/~cottrell/gretl-git-basics.html
>> with info an accessing the repository and translation from cvs commands
>> to git ones for basic operations.
>>
>>
> How does the logging-in work now? I used to do "ssh-add
> <my_SF_keyfile>", type in my passphrase, then "export
CVS_RSH=ssh",
> before I commit something with cvs. I guess at least the export command
> has to be changed.
>
I didn't have to do anything, ssh was clever enough to log me in
automatically as per usual.
Another thing that may be useful to CVS users: an operation that I would
perform very often (at least once a day, but often much more frequently
than that) was
cvs diff -uw
mainly to check what Allin had done during the night (time zones are _so_
nice). You now simply do
git diff
since unified format is the default for git.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
11:59 a.m.
On Fri, 2 Oct 2015, Hélio Guilherme wrote:
And there are a lot of good things to use with git. For example, I
use the
tool meld for merging and diff files.
Look for git mergetool and git difftool commands.
Install meld from http://meldmerge.org/
Thanks Allin for the good instructions you prepared (I'll see if I could
auto login for other github projects too).
While we're at it: the link below is a classic:
http://stackoverflow.com/questions/802573/difference-between-git-and-cvs
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6:07 p.m.
New subject: A question on eligibility of foreign languages interface packages
Dear all!
I wrote an R interface for panel data poisson regression for my post-graduate
econometrics classes. It can do slightly more than the original R
function (from {pglm}): it computes fixed effects and average marginal effects.
If it were only hansl work, I'd uploaded it to the server.
To my current knowledge, there are no official Gretl
packages providing interfaces to foreign functions.
Are such packages admissible?
Oleh
6:40 p.m.
New subject: A question on eligibility of foreign languages interface packages
Am 04.10.2015 um 20:07 schrieb oleg_komashko(a)ukr.net:
Dear all!
I wrote an R interface for panel data poisson regression for my post-graduate
econometrics classes. It can do slightly more than the original R
function (from {pglm}): it computes fixed effects and average marginal effects.
If it were only hansl work, I'd uploaded it to the server.
To my current knowledge, there are no official Gretl
packages providing interfaces to foreign functions.
Are such packages admissible?
Good question. One problem would be that an example script would not run
on a typical gretl installation, because one cannot presume the presence
of the respective foreign language.
OTOH there are certainly very useful applications for such packages, so
it would be a pity to ban them.
Perhaps a solution would be that somebody serves as a testing/contact
person for each foreign language. This person would have to check the
soundness of the example script (and the whole package) on his system.
(I would add "her" as an alternative to "his", but then I could also
write "Claudia" directly, I guess.)
cheers,
sven
8:06 p.m.
New subject: A question on eligibility of foreign languages interface packages
Dear Sven,
Thanks for hopeful comment.
First of all I mean R and Octave,
since the are as GNU as Gretl,
and the only marginal costs are
several (dozens) seconds to install.
I plan to include install.packages(c("pkg1","pkg2",....)
into the sample script, so the user has only
to install R and run the sample script once.
Besides, after Octave 4, Windows users don't
have to torture themselves: just download octave.exe
and enjoy!
Oleh
4 жовтня 2015, 21:40:51, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 04.10.2015 um 20:07 schrieb oleg_komashko(a)ukr.net:
> Dear all!
> I wrote an R interface for panel data poisson regression for my post-graduate
> econometrics classes. It can do slightly more than the original R
> function (from {pglm}): it computes fixed effects and average marginal effects.
>
> If it were only hansl work, I'd uploaded it to the server.
> To my current knowledge, there are no official Gretl
> packages providing interfaces to foreign functions.
> Are such packages admissible?
>
Good question. One problem would be that an example script would not run
on a typical gretl installation, because one cannot presume the presence
of the respective foreign language.
OTOH there are certainly very useful applications for such packages, so
it would be a pity to ban them.
Perhaps a solution would be that somebody serves as a testing/contact
person for each foreign language. This person would have to check the
soundness of the example script (and the whole package) on his system.
(I would add "her" as an alternative to "his", but then I could also
write "Claudia" directly, I guess.)
cheers,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:41 a.m.
New subject: A question on eligibility of foreign languages interface packages
On Sun, 4 Oct 2015, oleg_komashko(a)ukr.net wrote:
Dear Sven,
Thanks for hopeful comment.
First of all I mean R and Octave, since the are as GNU as Gretl, and
the
only marginal costs are several (dozens) seconds to install. I plan to
include install.packages(c("pkg1","pkg2",....) into the sample
script,
so the user has only to install R and run the sample script once.
I take your point, but it would be better if function packages could be
trusted to rely only on gretl and its own dependencies (gnuplot, latex
etc). Otherwise, users would need to maintain pieces of software they
don't really need just to use ONE feature.
Besides, I would imagine that writing a panel version of the poisson model
is perfectly possible in hansl. For example, what follows is a quick
replication of the fixed-effects Poisson example given in Greene's
textbook (7th ed), p. 822. It took me about half an hour to write it (and
it can surely be optimised, with analytical derivatives and all the rest).
<hansl>
function series llik(series y, series lambda)
ret = -lambda + y*ln(lambda) - lngamma(y+1)
return ok(y) ? ret : 0
end function
function series do_lambda(matrix beta, list X, series y)
series m = exp(lincomb(X, beta))
series ahat = ln(pmean(y) / pmean(m))
return exp(ahat) * m
end function
open http://www2.econ.univpm.it/servizi/hpp/lucchetti/gretl/rwm.gdt
setobs id year --panel-vars
list X = const age educ hhkids hhninc public
series y = ln(docvis+0.5)
ols y X --quiet
matrix b = $coeff[2:]
list X -= const
ym = pmean(docvis)
smpl ym>0 --restrict
mle ll = llik(docvis, lambda)
series lambda = do_lambda(b, X, docvis)
params b
end mle -vh
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:25 p.m.
New subject: A question on eligibility of foreign languages interface packages
On Mon, 5 Oct 2015, Riccardo (Jack) Lucchetti wrote:
On Sun, 4 Oct 2015, oleg_komashko(a)ukr.net wrote:
> Dear Sven,
> Thanks for hopeful comment.
> First of all I mean R and Octave, since the are as GNU as Gretl, and the
> only marginal costs are several (dozens) seconds to install. I plan to
> include install.packages(c("pkg1","pkg2",....) into the sample
script, so
> the user has only to install R and run the sample script once.
I take your point, but it would be better if function packages could be
trusted to rely only on gretl and its own dependencies (gnuplot, latex etc).
Otherwise, users would need to maintain pieces of software they don't really
need just to use ONE feature.
Besides, I would imagine that writing a panel version of the poisson model is
perfectly possible in hansl. [...]
I tend to agree with Jack on this. I can imagine that we might want to
set up a repository for interesting/useful applications of "foreign"
in gretl, but IMO this should be separate from our array of function
packages.
Allin
4:39 p.m.
New subject: A question on eligibility of foreign languages interface packages
Am 05.10.2015 um 18:25 schrieb Allin Cottrell:
On Mon, 5 Oct 2015, Riccardo (Jack) Lucchetti wrote:
I tend to agree with Jack on this. I can imagine that we might want to
set up a repository for interesting/useful applications of "foreign" in
gretl, but IMO this should be separate from our array of function packages.
Having a separate (and not accessible from within gretl) repository
sounds like a reasonable solution. The consolidated package format still
is very convenient to distribute something, even if it involves wrappers.
thanks,
sven
5:57 p.m.
New subject: A question on eligibility of foreign languages interface packages
Dear Allin,
I can imagine that we might want to
set up a repository for interesting/useful applications of "foreign"
in gretl, but IMO this should be separate from our array of function
packages.
I think, it's a very nice idea
I myself thought of proposing it yesterday
It can be a temporary solution before we will have proper hansl functions
For example, I will have nonlinear panel data classes in December.
I want to have, say 4-5 models with mfx's and diagnostics.
It's unrealistic to have it all in time.
But with foreign it's possible
The version of Riccardo deals with fixed effects
The interface can do poisson, negbin, pooling, randon, between, within and
detects time-constant varibles,,6 methods of optimization etc.
Besides, I have spent 4-5 times more computing the new thing: mfx's,
than making an interface
All in one: for me the separate repository is the best idea
Oleh
5 жовтня 2015, 19:25:10, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Mon, 5 Oct 2015, Riccardo (Jack) Lucchetti wrote:
> On Sun, 4 Oct 2015, oleg_komashko(a)ukr.net wrote:
>
>> Dear Sven,
>> Thanks for hopeful comment.
>
>> First of all I mean R and Octave, since the are as GNU as Gretl, and the
>> only marginal costs are several (dozens) seconds to install. I plan to
>> include install.packages(c("pkg1","pkg2",....) into the
sample script, so
>> the user has only to install R and run the sample script once.
>
> I take your point, but it would be better if function packages could be
> trusted to rely only on gretl and its own dependencies (gnuplot, latex etc).
> Otherwise, users would need to maintain pieces of software they don't really
> need just to use ONE feature.
>
> Besides, I would imagine that writing a panel version of the poisson model is
> perfectly possible in hansl. [...]
I tend to agree with Jack on this. I can imagine that we might want to
set up a repository for interesting/useful applications of "foreign"
in gretl, but IMO this should be separate from our array of function
packages.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
9:03 p.m.
New subject: A question on eligibility of foreign languages interface packages:the script
Dear all,
The script:
everybody can test and/or use
at the bottom are commented stata 12 commands
to compare
Oleh
5 жовтня 2015, 19:25:10, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Mon, 5 Oct 2015, Riccardo (Jack) Lucchetti wrote:
> On Sun, 4 Oct 2015, oleg_komashko(a)ukr.net wrote:
>
>> Dear Sven,
>> Thanks for hopeful comment.
>
>> First of all I mean R and Octave, since the are as GNU as Gretl, and the
>> only marginal costs are several (dozens) seconds to install. I plan to
>> include install.packages(c("pkg1","pkg2",....) into the
sample script, so
>> the user has only to install R and run the sample script once.
>
> I take your point, but it would be better if function packages could be
> trusted to rely only on gretl and its own dependencies (gnuplot, latex etc).
> Otherwise, users would need to maintain pieces of software they don't really
> need just to use ONE feature.
>
> Besides, I would imagine that writing a panel version of the poisson model is
> perfectly possible in hansl. [...]
I tend to agree with Jack on this. I can imagine that we might want to
set up a repository for interesting/useful applications of "foreign"
in gretl, but IMO this should be separate from our array of function
packages.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3119
days inactive
3123
days old
12 comments
5 participants
participants (5)
-
Allin Cottrell -
Hélio Guilherme -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber