Page 2 of 2

Re: newLISP Development Release v.10.6.3

Posted: Sat Jul 18, 2015 11:51 pm
by ralph.ronnquist
Whilst I bow to your experience in these matters, TedWalter, upon reflection I support Lutz in maintaining a practical barrier for code change. Obviously it can be done in different ways, but the way it's done certainly makes newlisp stable in respect of platform features and it's practical utility as scripting language. And I don't think this barrier plays much of a role for the uptake (or not) of newlisp, although admittedly this isn't something I've been thinking about.

Yes, the contributions it needs are more in the way of frameworks and infrastructural components supporting particular usage domains, than changes to the platform code. Maybe we should focus on the structuring, organisation and publishing of our various snippets of newlisp code, to make it easier for the casual visitor/user to pick up the required titbits for her collage.

The platform documentation is awesome, but when you want a snippet for doing your thing, you have to seek around among modules, tips and wherever, and basically know the solution you're looking for before you can find it. Perhaps that's the egg here; a large enough user community will make enough web noise to let me find my solution by voicing my problem.

Re: newLISP Development Release v.10.6.3

Posted: Sun Jul 19, 2015 9:47 pm
by xytroxon
After spending a couple of hours in a time warp after an unexpected date-value function crash in a weekly archive program I run.

((( Yes, I NOW know about: viewtopic.php?f=16&t=4725

(PLEASE, post about devlopment release errors in the development release thread!!!) )))

I noticed a peculiarity in the date function example in the newLISP manual:

(date 0 (now 0 -2)) -> "Thu Jan 1 00:00:00 1970" ; Unix epoch

Which when executed on Win 7 returns -> nil

In my time zone: (now 0 -2) -> -420

Inverting the sign to +420 gives the expected* result:

(date 0 (* (now 0 -2) -1)) -> "Thu Jan 01 00:00:00 1970"

Is this a newLISP coding error, or a devious "design feature" from the ancient UNIX/C system gods - IE C system time functions returning and needing the time zone expressed with different sign values?

-- Dr Who... er. xytroxon

* My expected result would be:

(date 0) -> "Thu Jan 01 00:00:00 1970"
(date 0 -420) -> "Wed Dec 31 17:00:00 1969"

But then, I am not a UNIX/C system god ;o)

Re: newLISP Development Release v.10.6.3

Posted: Sun Jul 19, 2015 10:55 pm
by Lutz
date without offset parameter displays local time and also adjusted for daylight savings time (e.g. in California). now displays UTC (universal time) and the number of minutes your are behind (minus for west of Greenwich) or ahead (plus for east of Greenwich) of UTC.

Also, Windows cannot handle negative values before Unix epoch and returns nil and not all OS deliver a valid indication for the daylight savings time or encode it in different ways.

Ps: there is a problem with the UTC offset in now on 10.6.3 on Windows 64-bit compiles corrected in the latest 10.6.4. The UTC offset in Windows also not includes the daylight saving offset, but may in final 10.6.4, to make at least the UTC offset portable between Windows and Unix.

Re: newLISP Development Release v.10.6.3

Posted: Sun Aug 09, 2015 8:40 pm
by kosh
Lutz wrote:Thanks for the configure-alt fix. It works now, but on a Windows 7 64-bit systems it also compiles a 32-bit newlisp.exe and without libffi using the TDM GCC 64 toolset.

I am not too concerned about this, as we have working Windows 32/64-bit compilations using the normal configure script and the TDM GCC 64 toolset. It can use the mingw64 to compile 32-bit newlisp.exe with libffi without any error messages. using make winall or make winall64, the executables for the Windows installers are done together with DLLs.
It means that newLISP drop support on previous MinGW32 toolset, and migrate to TDM-GCC 32/64 toolset?

Re: newLISP Development Release v.10.6.3

Posted: Mon Aug 10, 2015 1:44 pm
by Lutz
Yes, the TDM-GCC 32/64 toolset, it also seems to use MinGW but is easier to install and compiles both: 32-bit and 64-bit executables and DLLs with less problems. The GCC used seems to be a 32-bit executable, not 64-bit as earlier stated. The installation comes with both 32-bit and 64-bit libraries. The only thing I add are two libffi.a files for 32 and 64 bit to the appropiate library directories and MSYS for make and other Unix tools.

Re: newLISP Development Release v.10.6.3

Posted: Sun Sep 20, 2015 6:15 am
by xytroxon
newLISP manual spelling error.

syntax: (delete-file str-url)