string bug with non-ASCII chars
by Sven Schreiber
Hi,
this is about string slicing, with snapshot March 9th:
<hansl>
string sf = sprintf("123\n456")
print sf # correct
eval sf[1:7] # correct
sf = sprintf("123\n456§")
print sf # correct
eval strlen(sf) # correct
eval sf[1:8] # stops after \n
eval substr(sf, 1, 8) # correct
</hansl>
Just in time for release?
thanks,
sven
7 years
bug (?) with max on list
by Sven Schreiber
Hi,
shouldn't this work? Getting an unmatched data types or something error.
thanks,
sven
<hansl>
nulldata 2
series a = 10 # ID 2 (1 is index)
series b = 11 # ID 3
eval max(deflist(1,2,3))
</hansl>
7 years
beginner's (but understandable) problem on the console
by Sven Schreiber
Hi,
I'm relaying a usability issue report which I think could lead to
improvements.
(This is not meant for the release in progress, but in general.)
First, if you type in an expression on the console, gretl will not
automatically evaluate it. Instead we have the 'eval' command. However,
most interpreted programming languages out there will directly spit out
the result on what you type in at the prompt. Why not gretl?
Or to put it more formally: I suggest that whenever gretl's parser
cannot make sense of the console input and would respond with an error
message, it should try to automatically prepend an 'eval' and see if
that works.
Secondly (a minor bug), sometimes you get the error message "incomplete
expression", for example if you type in "y[2]" instead of "eval y[2]".
But this message is misleading, because as an _expression_ in a computer
science sense y[2] is perfectly valid I think. Instead the error could
read, "incomplete command" or perhaps "incomplete statement".
thanks,
sven
7 years
Help about git
by yinung＠Gmail
Hi,
I would like to update the translation PO files but I failed.
I got the following message in terminal. How should I do?
Thanks.
yinung
yinung@mint18 ~/git/gretl-git $ git pull
Password:
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
>From ssh://git.code.sf.net/p/gretl/git
2abb460..ae3f7c3 master -> origin/master
Auto-merging po/zh_CN.po
CONFLICT (content): Merge conflict in po/zh_CN.po
Automatic merge failed; fix conflicts and then commit the result.
7 years
Fwd: Re: slight inconsistency with strstr truth value
by Sven Schreiber
[sent only to jack instead of the list by mistake]
Anfang der weitergeleiteten E-Mail
> Von: "Sven Schreiber" <svetosch(a)gmx.net>
> Datum: 12. März 2018 um 08:54
> An: r.lucchetti(a)univpm.it
> Betreff: Re: [Gretl-devel] slight inconsistency with strstr truth value
>
> Am 12.03.18 um 08:30 schrieb Riccardo (Jack) Lucchetti
>
>
> > I'm sorry I'm chiming in only at this stage, but I find the whole issue
> > quite confusing. In my view, Hansl should not aim at being too clever with
> > strings. There already are many tools that are much better at that than
> > Hansl will ever be (Python of course springs to mind). Maybe I'm being a
> > little too conservative here, but in my eyes a Boolean expression is
> > something that should unambiguously map to 0 or non-zero. True, "if foo"
> > (foo being a string) can be interpreted as shorthand for "if strlen(foo)",
> > but then the problem arises on cases like
> >
> > if foo || bar
> > if foo && bar
> > if foo * bar
> > if foo + bar
> > if !foo
> >
> > ("bar" being some arbitrary variable, such as a string but also possibly a
> > scalar, a matrix etc), etcetera, in which we would have first to guess
> > whether the intended outcome is Boolean or not and then act accordingly.
> >
> > Too complicated IMO. If it weren't for backward compatibility, I'd ban "if
> > <string>" altogether, but at this point I would guess we could allow "if
> > foo" (where "foo" is a named string, but not something that evaluates to a
> > string) for historical reasons, but no more than
>
> Yes, I think that s the conclusion we’ve reached as well. And because it was undocumented “if foo” will also be banned after the respective function packages (mine, perhaps Oleh’s?) have been adjusted. At least that’s my interpretation of the discussion.
>
> Cheers
> Sven
7 years
slight inconsistency with strstr truth value
by Sven Schreiber
Hi,
see this:
<hansl>
if strstr("abc", "a")
print "yes"
endif
if (1 == 1) && strstr("abc", "a") != ""
print "aha"
endif
if (1 == 1) && strstr("abc", "a")
print "oho"
endif
</hansl>
The last thing gives an error, where I would expect that if the first
variant works, then so should the third/last one. Workaround is the
second explicit thing, obviously.
thanks,
sven
7 years
Windows: .../Documents/gretl/functions dir
by Sven Schreiber
Hi,
AFAIU on Windows gretl also searches in the path
C:\users\<userid>\Documents\gretl\functions for packages.
But does gretl also actively create this directory at any point? I don't
remember how it was on my machine(s), but on a different system with
gretl that path is absent.
thanks,
sven
7 years
gretl data bases (.bin) question
by oleg_komashko＠ukr.net
Dear all,
If I do not a mistake, weekly and
daily data as year:number (2017:40, etc)
can not be saved to a .bin database
There are several formats for weekly/daily data
Is there any possibility to save weekly/daily data
into databases as weekly/daily
Oleh
7 years
broken link in package guide
by Sven Schreiber
Hi,
in footnote 1 of the package guide pkgbook.pdf (March 2018 version), p.38:
http://sourceforge.net/p/gretl/git/ci/master/tree/gui2/
Obviously due to change from gui2 to gui. Maybe somewhere else as well,
web page?
BTW, here on Windows by default an outdated version of pkgbook.pdf gets
picked: The older one lives in
c:\users\<name>\AppData\Roaming\gretl\doc, while the recent one is in
c:\program files\gretl\doc.
(As always, I'm very lazy when installing new snapshots and do not
really remove the previous versions.)
thanks,
sven
7 years
next release
by Allin Cottrell
Hello all,
Now that sourceforge seems to be in full swing again, my thoughts
are returning to the delayed 2018a release.
There are new snapshots in place today; I'd be grateful if people
could give them a go and check that nothing has gone badly wrong.
Since we've had a flurry of bug reports (or at least, "infelicity
reports") over the last few weeks, and I've made quite a few changes
in response, I'd like to make sure that my new changes haven't
broken anything serious.
Allin
7 years
