defbundle parsing
by Sven S
Hi,
the following line works, but shouldn't it fail due to the trailing comma?:
bundle b = defbundle("a",1 ,)
thanks
sven
3 years, 3 months
x-range for scatters using daily data
by Artur Tarassow
Hi all,
the following script yields a plot for which the x-range goes far beyond
2020-02-28 when using daily data. I use latest git version on Ubuntu 19.10.
<hansl>
clear
set verbose off
nulldata 40
setobs 7 2020-01-20
delete index
series a = normal()
series b = normal()
list L = dataset
# x-axis shows all the way long up to 2021
scatters L --with-lines --output=display
</hansl>
Thanks,
Artur
4 years
Readable aliases true/false
by Sven Schreiber
Hi,
sorry, here is another one of those free-floating wishlist items: Some
complex packages have functions with quite many arguments, among which
often some boolean switches. The function calls would be easier to read
if one could use some keywords for on-off/yes-no/true-false instead of
the generic 1-0 (where it could be another general integer arg of course).
So could gretl have trivial constants simply mapped to 1 and 0? For
example like additional $-accessors: $true $false.
If we don't want to have it as built-in stuff, one alternative could be
to add functions true() and false() (without arguments I guess) to the
extra package.
cheers
sven
4 years
Windows build 2020a
by Sven Schreiber
Hi everybody and especially Allin of course,
I just remembered that I had tried again to build gretl (2020a) on
Windows last week but still got some errors. I will see if I can re-run
that thing and post the details.
cheers
sven
4 years
revisions to build process
by Allin Cottrell
Here's something that people building gretl from the git sources
should note. (It's not relevant if you're building from a released
source package.)
I've recently revised the Makefiles for the gretl documentation
(both "online" and PDF). This was motivated by build problems on
Windows, but more generally I'm trying to ensure that the docs get
(re-)built always and only when they're non-existent or out of date.
As part of this effort I've changed the location of the compiled
helpfiles, namely
gretl_cli_cmdref.<lang>
gretl_gui_cmdref.<lang>
gretl_gui_help.<lang>
gretl_cli_fnref.<lang>
gretl_gui_fnref.<lang>
gretlhelp.refs
We used to do something kinda anomalous: even when building outside
of the source tree we wrote these files into the "share"
subdirectory of the source tree itself (rationale: so they were
automatically in place for a non-git source package).
Now these files get written to doc/commands in the build tree (and
"make install" is revised to find them OK).
That means that you can safely delete the "orphan" versions under
<src>/share, as in
cd <your-gretl-source>/share
rm -f gretl_*ref.* gretl_gui_help.* gretlhelp.refs
Also, I've got rid of the "stamp" files that we were using to signal
that the helpfiles had been built -- with the exception of one
called fig.stamp. So you can clean these up in <src>/share:
rm -f *.stamp # delete all
touch fig.stamp # but reconstitute this one
I still need to think about how best to get rid of fig.stamp.
Allin
4 years
Problem with ODBC query
by Artur Tarassow
Hi all,
At least with latest git version on Ubuntu 18.10, I am experiencing
problems with ODBC. Both of the following queries are pretty standard,
and I've succesfully used the first one before. Stuff also works fine
using the isql client via the terminal.
<QUERY_1>
open dsn=@DSN user=@USER password=@PW --odbc
data klima query="SELECT KLIMA FROM OV_AS_LAB_LUMEN.IFO_DATA" --odbc
</QUERY_1>
<ERROR_1>
ERROR: Error executing script: halting
> data klima query="SELECT KLIMA FROM OV_AS_LAB_LUMEN.IFO_DATA" --odbc
</ERROR_1>
The weird thing is that I obtain a new series but which has only zero
values which is wrong.
<TERMINAL_1>
SQLDisconnect(dbc): SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_DBC, dbc): SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_ENV, OD_env): SQL_SUCCESS
SQL query: 'SELECT KLIMA FROM OV_AS_LAB_LUMEN.IFO_DATA'
Number of columns = 1
col 1 (KLIMA): data_type SQL_DECIMAL, size 4, digits 1, nullable 2
Number of Rows (from SQLRowCount) = 1886
SQLFreeHandle(SQL_HANDLE_STMT): SQL_SUCCESS
SQLDisconnect: SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_DBC): SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_ENV): SQL_SUCCESS
</TERMINAL_1>
Here "sektor" is a string variable.
<QUERY_2>
open dsn=@DSN user=@USER password=@PW --odbc
data sektor query="SELECT SEKTOR FROM OV_AS_LAB_LUMEN.IFO_DATA" --odbc
</QUERY_2>
<ERROR_2>
ERROR: Error executing script: halting
> data sektor query="SELECT KLIMA FROM OV_AS_LAB_LUMEN.IFO_DATA" --odbc
</ERROR_2>
Again I get a new series but all values are missings which is also wrong.
<TERMINAL_2>
SQLDisconnect(dbc): SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_DBC, dbc): SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_ENV, OD_env): SQL_SUCCESS
SQL query: 'SELECT SEKTOR FROM OV_AS_LAB_LUMEN.IFO_DATA'
Number of columns = 1
col 1 (SEKTOR): data_type SQL_VARCHAR, size 20, digits 0, nullable 2
binding data col 1 to strvals[0] (len = 20)
Number of Rows (from SQLRowCount) = 1886
SQLFreeHandle(SQL_HANDLE_STMT): SQL_SUCCESS
SQLDisconnect: SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_DBC): SQL_SUCCESS
SQLFreeHandle(SQL_HANDLE_ENV): SQL_SUCCESS
</TERMINAL_2>
Any idea what's going on here?
Thanks,
Artur
4 years
Re: Windows build 2020a/b
by Sven Schreiber
Am 28.03.2020 um 14:37 schrieb ESTEVEZ NUÑEZ JUAN CARLOS:
> No, Sven. I run the files as is.
> I had only 2 problems. The first, I think that was a conflict between
> my Antivirus updates and old msys instalation.
> So I clean and install, msys64 again. Then I tried the instalation (12
> hours ago) but finished with some warnings related with Latex.
> I tried today again, and all seems to work fine.
OK thanks. Maybe I need to clean up more aggressively before re-trying...
cheers
sven
4 years, 1 month
Re: Windows build 2020a/b
by Sven Schreiber
Am 28.03.2020 um 12:36 schrieb ESTEVEZ NUÑEZ JUAN CARLOS:
> Dear Allin and Sven,
>
> I had problems to Win-build gretl last night (maybe related to some
> Latex commands) but now it goes fine to me.
> I´ve just done it, running setup.sh (as is in repository), and making
> a distributable package (running pkgbuild.sh as is).
> There seems not to be problems with both instalations. I tested:
> This was made on Win 10 Pro 64-bit and msys64.
> univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
Hi Juan, very interesting, thanks for the feedback. So you haven't
customized anything, no different configuration (conf.sh) or a different
TeX setup?
thanks
sven
4 years, 1 month
release? and funcerr() revisited
by Allin Cottrell
I'm thinking that an early 2020b release would be good, to address
the macOS Catalina security issue (about which we'll probably hear
more).
In that context, I think most of the changes since 2020a are
harmless, with the possible exception of the modification of
funcerr(), so I'd like to revisit that.
Quick recap:
(1) For some time we've had a "funcerr" command, which triggers an
early return from a function with an error flagged; it has an
optional argument, namely a specific message to be displayed.
(2) Before the 2020a release we added a function version of this,
the point being that in a function argument (unlike a command
argument) you could factor in a call to sprintf(), hence saving a
line of code if you wanted to show a context-dependent message.
(3) More recently I extended funcerr() to take two arguments: first
a boolean error condition, then the message. This could save another
two lines of code: instead of wrapping the call to funcerr in "if"
and "endif" you could embed the condition in the funcerr() call
(which would then not trigger if the boolean were false).
Here are my second thoughts. Usually when we offer a function
version of a command it's just a matter of adding convenience, for
users comfortable with function calls, with no change in semantics
relative to the command. That's true of the first version of
funcerr() but not the latest one. So my latest change is kinda
unruly.
If we were willing to add a new function we might call it "iferror",
as in
iferror(error_condition, message)
This would work just like the new funcerr(), but funcerr() itself
would revert to its usage in 2020a, parallel to the command. Any
thoughts?
Allin
4 years, 1 month
Re: continue statement for flow control
by Artur Tarassow
Hi Sven,
sorry for the delay on this.
Am 09.03.20 um 19:22 schrieb Artur Tarassow:
> Am 08.03.20 um 22:42 schrieb Sven Schreiber:
>> Am 08.03.2020 um 20:18 schrieb Artur Tarassow:
>>
>>> changed early in the loop. Let me come up with a constructed example
>>> -- I hope it shows my point for the usefulness of such a statement:
>>
>> I would agree that in some ways the hansl syntax is less flexible than
>> that of other programming languages. However, I guess you need a
>> better or "more sharpened" example.
>
> Hi, I admit that the example isn't very convincing -- just supposed to
> be a simple illustration of the issue.
>
>> For example, I can rewrite your demonstration as follows:
>>
>>> <hansl>
>>> scalar k = 2
>>> loop i=1..3 -q
>>>
>>> scalar n = randgen1(i, 0, 3)
>>> if n == 0
>>> # get out here and proceed with i++
>>> else
>>> if n == 1
>>> # get out here and proceed with i++
>>> else
>>> # do something clever here
>>> if k > 2
>>> # get out here and proceed with i++
>>> else
>>> # do something clever here
>>> endif
>>> endif
>>> endif
>>> endloop
>>
>> ...
>> if n==0
>> ...
>> elif n==1
>> ...
>> elif k > 2
>> ...
>> else
>> ...
>> endif
>>
>> which is pretty clean without any 'continue' statement.
>
> If it could always be solved like this, I guess their would be no need
> for the "continue" statement in C ;-)
In principle, the continue statement is not needed to write workable
code. But it is a very convenient tool for writing more readable code.
Especially when code includes (many) nested if-statements.
I agree my example is not well chosen as it can be reduced to a few
simple lines as you have shown. But of course this is not always the
case. "continue" would make some stuff just simpler and _cleaner_ (more
logically structured) to write.
Best,
Artur
4 years, 1 month
