3:10 p.m.
Hi all,
the doc says that $sysinfo.os gives "linux", "osx",
"windows" or other
as a piece of introspection. An older accessor is $windows, which
returns 0 or 1.
So the $windows accessor appears redundant and doesn't cover the Mac -
should it perhaps be discouraged for new hansl scripts? (I guess
$sysinfo.os has been around long enough such that there are no real
compatibility issues.) At least I guess the doc for $windows should also
point to $sysinfo.os.
As a further minor point, AFAIK MacOS is not named "OS X" anymore. But
obviously, changing the return string to "macos" or something like that
would raise backwards compatibility problems. Again, maybe the easiest
thing is simply to add a note to the doc?
thanks
sven
3:59 p.m.
On Sat, 23 Oct 2021, Sven Schreiber wrote:
Hi all,
the doc says that $sysinfo.os gives "linux", "osx",
"windows" or other
as a piece of introspection. An older accessor is $windows, which
returns 0 or 1.
So the $windows accessor appears redundant and doesn't cover the Mac -
should it perhaps be discouraged for new hansl scripts? (I guess
$sysinfo.os has been around long enough such that there are no real
compatibility issues.) At least I guess the doc for $windows should also
point to $sysinfo.os.
As a further minor point, AFAIK MacOS is not named "OS X" anymore. But
obviously, changing the return string to "macos" or something like that
would raise backwards compatibility problems. Again, maybe the easiest
thing is simply to add a note to the doc?
My take on this is that it's very unlikely that anyone wants to
branch in a script based on "osx" versus "linux" since they're
both
at core unix variants. So we should be safe just updating the string
under $sysinfo.os from "osx" to "macos".
MS Windows is definitely the odd man out. For that reason I'd say
it's worth preserving the $windows accessor, which is a lightweight
alternative to producing the full $sysinfo bundle if a script or
package writer just wants to enable special treatment for Windows.
Allin
4:11 p.m.
Am 23.10.2021 um 21:59 schrieb Allin Cottrell:
My take on this is that it's very unlikely that anyone wants to
branch
in a script based on "osx" versus "linux" since they're both at
core
unix variants. So we should be safe just updating the string under
$sysinfo.os from "osx" to "macos".
Well, as it happens, I have a non-public package which checks for "osx"
because it has to give up in that case.
One solution might be to change the string to "osx macos" and recommend
the use of instring() as a check, so checking for "osx" and "macos"
would both work, with old and new gretl versions. But OTOH maybe it's
not really worth touching it and better just add a note in the doc...
MS Windows is definitely the odd man out. For that reason I'd say
it's
worth preserving the $windows accessor, which is a lightweight
alternative to producing the full $sysinfo bundle if a script or package
writer just wants to enable special treatment for Windows.
OK, sounds reasonable!
thanks
sven
4:19 p.m.
On Sat, 23 Oct 2021, Sven Schreiber wrote:
Am 23.10.2021 um 21:59 schrieb Allin Cottrell:
> My take on this is that it's very unlikely that anyone wants to branch
> in a script based on "osx" versus "linux" since they're both
at core
> unix variants. So we should be safe just updating the string under
> $sysinfo.os from "osx" to "macos".
Well, as it happens, I have a non-public package which checks for "osx"
because it has to give up in that case.
Hmm, what is definitely not going to work on macOS?
Allin
6:32 a.m.
On 23.10.2021 21:59, Allin Cottrell wrote:
On Sat, 23 Oct 2021, Sven Schreiber wrote:
My take on this is that it's very unlikely that anyone wants to branch
in a script based on "osx" versus "linux" since they're both at
core
unix variants. So we should be safe just updating the string under
$sysinfo.os from "osx" to "macos".
Current build for MacOS run in Darling on my machine:
Darling [/Applications/Gretl-new.app/Contents/Resources/bin]$ ./gretlcli
via localeconv, decimal = ','
gretl version 2021e-git
Copyright Ramu Ramanathan, Allin Cottrell and Riccardo "Jack" Lucchetti
This is free software with ABSOLUTELY NO WARRANTY
Current session: 2021-10-24 12:28
gretl is process 235,
'/home/marcin/.darling/Applications/Gretl-new.app/Contents/Resources/bin/gretlcli'
gretldir is maybe
'/home/marcin/.darling/Applications/Gretl-new.app/Contents/Resources/share/gretl/'?
help file
/home/marcin/.darling/Applications/Gretl-new.app/Contents/Resources/share/gretl/gretl_cli_cmdref.en
is not accessible
gretl: using these basic search paths:
gretldir:
/home/marcin/.darling/Applications/Gretl-new.app/Contents/Resources/share/gretl/
workdir: /Users/marcin/gretl/
dotdir: /Users/marcin/.gretl/
gnuplot:
/home/marcin/.darling/Applications/Gretl-new.app/Contents/Resources/bin/gnuplot
Type "open filename" to open a data set
? eval $sysinfo
failed to get VM statisticsbundle:
mpi = 0
mpimax = 8
ncores = 4
nproc = 8
omp = 1
wordlen = 64
mem (matrix: 1 x 2)
blas = "veclib"
hostname = "marcin-note"
os = "macos"
foreign (bundle)
?
Unforatunatelly I cannot run gretl in GUI since my darling claims I
don't have atk-bridge, but... machine for cross-compilations works!!!
Marcin
--
Marcin Błażejowski
7:12 a.m.
Am 23.10.2021 um 22:19 schrieb Allin Cottrell:
On Sat, 23 Oct 2021, Sven Schreiber wrote:
> Am 23.10.2021 um 21:59 schrieb Allin Cottrell:
>
>> My take on this is that it's very unlikely that anyone wants to branch
>> in a script based on "osx" versus "linux" since they're
both at core
>> unix variants. So we should be safe just updating the string under
>> $sysinfo.os from "osx" to "macos".
>
> Well, as it happens, I have a non-public package which checks for "osx"
> because it has to give up in that case.
Hmm, what is definitely not going to work on macOS?
I'm helping Ekkehart in wrapping his standalone C program with a gretl
function package that calls the respective executables. A prototype is
already working nicely (in principle) on Windows and Linux. There is no
executable for MacOS, however, and that's why I need to test for this
platform, not just for Windows. Also if there were such a binary in the
future, it would surely be different from the Linux one, so the test
remains necessary, I'd say. If $sysinfo.os doesn't spit out "osx"
anymore, then the package will be broken on gretl versions <2021e.
thanks
sven
7:13 a.m.
Am 24.10.2021 um 12:32 schrieb Marcin Błażejowski:
On 23.10.2021 21:59, Allin Cottrell wrote:
> On Sat, 23 Oct 2021, Sven Schreiber wrote:
>
> My take on this is that it's very unlikely that anyone wants to branch
> in a script based on "osx" versus "linux" since they're both
at core
> unix variants. So we should be safe just updating the string under
> $sysinfo.os from "osx" to "macos".
Current build for MacOS run in Darling on my machine:
...
os = "macos"
Thanks, Marcin - this is because Allin changed it yesterday, see
https://sourceforge.net/p/gretl/git/ci/6e46d15a4d46cdd0da3bb6e455bffd0638...
cheers
sven
7:50 a.m.
On Sun, 24 Oct 2021, Sven Schreiber wrote:
Am 23.10.2021 um 22:19 schrieb Allin Cottrell:
> On Sat, 23 Oct 2021, Sven Schreiber wrote:
>
>> Am 23.10.2021 um 21:59 schrieb Allin Cottrell:
>>
>>> My take on this is that it's very unlikely that anyone wants to branch
>>> in a script based on "osx" versus "linux" since
they're both at core
>>> unix variants. So we should be safe just updating the string under
>>> $sysinfo.os from "osx" to "macos".
>>
>> Well, as it happens, I have a non-public package which checks for
"osx"
>> because it has to give up in that case.
>
> Hmm, what is definitely not going to work on macOS?
I'm helping Ekkehart in wrapping his standalone C program with a gretl
function package that calls the respective executables. A prototype is
already working nicely (in principle) on Windows and Linux. There is no
executable for MacOS, however, and that's why I need to test for this
platform, not just for Windows. Also if there were such a binary in the
future, it would surely be different from the Linux one, so the test
remains necessary, I'd say. If $sysinfo.os doesn't spit out "osx"
anymore, then the package will be broken on gretl versions <2021e.
How about:
<hansl>
function scalar on_macos (void)
string os = $sysinfo.os
return os == "macos" || os == "osx"
end function
</hansl>
Allin
8:22 a.m.
Am 24.10.2021 um 13:50 schrieb Allin Cottrell:
On Sun, 24 Oct 2021, Sven Schreiber wrote:
> Am 23.10.2021 um 22:19 schrieb Allin Cottrell:
>> On Sat, 23 Oct 2021, Sven Schreiber wrote:
>>
>>> Am 23.10.2021 um 21:59 schrieb Allin Cottrell:
>>>
>>>> My take on this is that it's very unlikely that anyone wants to
branch
>>>> in a script based on "osx" versus "linux" since
they're both at core
>>>> unix variants. So we should be safe just updating the string under
>>>> $sysinfo.os from "osx" to "macos".
>>>
>>> Well, as it happens, I have a non-public package which checks for
"osx"
>>> because it has to give up in that case.
>>
>> Hmm, what is definitely not going to work on macOS?
>
> I'm helping Ekkehart in wrapping his standalone C program with a gretl
> function package that calls the respective executables. A prototype is
> already working nicely (in principle) on Windows and Linux. There is no
> executable for MacOS, however, and that's why I need to test for this
> platform, not just for Windows. Also if there were such a binary in the
> future, it would surely be different from the Linux one, so the test
> remains necessary, I'd say. If $sysinfo.os doesn't spit out "osx"
> anymore, then the package will be broken on gretl versions <2021e.
How about:
<hansl>
function scalar on_macos (void)
string os = $sysinfo.os
return os == "macos" || os == "osx"
end function
</hansl>
OK, that would be a solution. Or simply:
'instring("macos osx", $sysinfo.os)'
But I agree that 'if on_macos' is a nicer idiom.
thanks
sven
3:17 a.m.
Am 24.10.2021 um 14:22 schrieb Sven Schreiber:
Am 24.10.2021 um 13:50 schrieb Allin Cottrell:
> On Sun, 24 Oct 2021, Sven Schreiber wrote:
>
>> Am 23.10.2021 um 22:19 schrieb Allin Cottrell:
>>> On Sat, 23 Oct 2021, Sven Schreiber wrote:
>>>
>>>> Am 23.10.2021 um 21:59 schrieb Allin Cottrell:
>>>>
>>>>> My take on this is that it's very unlikely that anyone wants to
>>>>> branch
>>>>> in a script based on "osx" versus "linux" since
they're both at core
>>>>> unix variants. So we should be safe just updating the string under
>>>>> $sysinfo.os from "osx" to "macos".
So should this change be added to the incompatibility log?
thanks
sven
1061
days inactive
1078
days old
9 comments
3 participants
participants (3)
-
Allin Cottrell -
Marcin Błażejowski -
Sven Schreiber