On Fri, 18 Nov 2016, Sven Schreiber wrote: I'm not sure what's the best thing to do about this. I believe the original thought about lists was that if you say list L = null you get a valid list object with no members. So, by extension, if a list parameter to a function is marked as having a default of "null", this suggests that in the absence of an argument the parameter slot should be automatically filled with a list with no members -- and that's what happens at present. However, there's an inconsistency with strings, as you say. Unfortunately (as it now seems to me), you can say string s = null and get an empty string. So one could argue that for consistency with lists we should automatically supply a zero-length string when a string parameter is marked with a "null" default and no argument is given. I say "unfortunately" because there's a perfectly good and unambiguous way to get an empty string, namely string s = "" and allowing "string s = null" seems not quite right. Anyway... we could regularize this by dropping the current practice of manufacturing an empty list corresponding to no-argument, although this would mean that "null" has a somewhat different meaning on the right-hand side of an assignment (empty object) and as the default for a function argument (non-existent). Urgh. It's hard to see a way out of this that's not rather nastily backward-incompatible. Allin

On Fri, 18 Nov 2016, Riccardo (Jack) Lucchetti wrote: Totally agreed, we can't do that. But less obviously havoc-wreaking would be to change the behavior of list function-parameters with a "null" default so that the callee gets no list rather than an empty list when no argument is supplied. Not that I'm actually recommending that. It might well break a bunch of scripts too. Sure, it works fine, for lists. But Sven's point is that you have to use a different argument-checking construction for lists than you use for function-arguments of other types that support a "null" default value. The easiest (though not the tidiest) thing to do here is just be clear in the doc that lists are special in this respect. Allin

Am 18.11.2016 um 17:45 schrieb Allin Cottrell: No, I think that would be too disruptive. ... Absolutely, that was the point of my original post. Lists are also special in other ways (e.g., cannot be in bundles, partly break the encapsulation of functions), so I think keeping it special here isn't too bad. However, the new thing that has come up in this thread is the situation with 'string s = null' after which exists(s)==1 and even more paradoxically isnull(s)==0. And which is different from a function parameter default 'string s[null]' which produces exists(s)==0 inside the function. So I think this needs fixing (in the short term). Perhaps another long-term solution might also be needed (new keyword "none" for defaults, or empty brackets "[]"?). cheers, sven

Am 18.11.2016 um 19:08 schrieb Allin Cottrell: Yes, and it's OK that it simply and always returns the complement to exists(). However, it's still described in section 13.4 of the guide (in the context of optional pointer arguments). In principle that would be fine with me (although the status quo is according to the spec in ch.14). OTOH when you say that one can always do 'string s=""', then one could also argue that one can do "strings ss=defarray()" or "strings ss=array(0)", and similarly for the other array types (matrices, bundles). So I'd tend to think that we should ditch the "null" business either everywhere or nowhere. Let's compare the situation to scalar function arguments: There "null" is not allowed (let's leave the pointer stuff aside for now) because you can assign some default value and that's enough. Why not do the same for string arguments, actually? Examples: string s[""] # empty string by default string s["heyho"] # or --new feature-- some arbitrary literal string thanks, sven

On Wed, 23 Nov 2016, Ignacio Diaz-Emparanza wrote: I tried running this with the current 64-bit snapshot on Windows 8, in Spanish and with decimal comma selected under Preferences: no crash, the plot is displayed correctly. I then uninstalled the 64-bit version and tried the 32-bit build. Same result. So at this point I have no idea what might be happening in your case. Could you try running gretl with the --debug flag and see if anything relevant appears on stderr? Thanks. Allin

On Thu, 24 Nov 2016, Ignacio Diaz-Emparanza wrote: OK, thanks for sending the screenshot. I'll have to think some more about what might be going on. Allin

El 24/11/16 a las 19:00, Allin Cottrell escribió: Yes, I also have a crash with this. In fact the problem is the line set force_decpoint on An script with only this line makes gretl to crash. But set force_decpoint off runs ok. -- Ignacio Díaz-Emparanza Departamento de Economía Aplicada III (Econometría y Estadística) Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU Tfno: (+34) 94 601 3732 http://www.ehu.eus/ea3

El 25/11/16 a las 11:31, Sven Schreiber escribió: I saw this first in a gretl instalation from april 2015 on Windows 7 (Our university is officially anchored to Windows 7). Then I checked that this also occurs with the current snapshot (in a Windows 7 in a Virtual machine on my PC). Probably. I did'nt knowthat this had any importance. But I have learnt it now. I will try not to do so in the future. -- Ignacio Díaz-Emparanza Departamento de Economía Aplicada III (Econometría y Estadística) Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU Tfno: (+34) 94 601 3732 http://www.ehu.eus/ea3

El 25/11/16 a las 15:32, Allin Cottrell escribió: Yes it occurs also with the current snapshot. Windows propose to send some files, about the crash, to Microsoft. I will send them to you in private, because it may give some extra information (I don't understand their content) -- Ignacio Díaz-Emparanza Departamento de Economía Aplicada III (Econometría y Estadística) Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU Tfno: (+34) 94 601 3732 http://www.ehu.eus/ea3