Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - nigelbrown

Pages 1 ... 26 27 28 29
#406
newLISP in the real world / passing pipe to process?
November 26, 2003, 06:58:12 PM
In the ref man it says:

syntax: (pipe)

pipe creates an interprocess communications pipe and returns the read and write handles

to it in a list. This function is only available on Linux/BSD compiles and not working on the

Win32 or CYGWIN versions.

(pipe) => (3 4) ; 3 for read, 4 for writing

The pipe handles can be passed on to a child process launched via process for inter process

communications.



QUESTION: How are the pipe handles passed to process (on linux of course)?



The man gives for process:

process

syntax: (process str−command)

process works similar to ! but in a non−blocking fashion, launching a child−process

specified in str−command and then returning immeadeately with true.

example:

(process "notepad") => true

See also pipe for interprocess communications.
#407
Anything else we might add? /
November 24, 2003, 03:38:31 PM
Hi

regarding

>You tested assoc with symbol nil. When you test against a var which is nil,

>you get: The variable is unbound.



Assoc will do the same with nil and a variable bound to nil - the behaviour you described would occur is an unbound variable is passed to assoc -

example in Corman Lisp using the variable 'a' :

a

;;; An error occurred in function #< COMPILED-FUNCTION: #xD27570 >:

;;; Error: The variable A is unbound

...

(assoc 'r nil)

NIL

(assoc 'r a)

;;; An error occurred in function #< COMPILED-FUNCTION: #xD7D638 >:

;;; Error: The variable A is unbound

;;; Entering Corman Lisp debug loop.

...

;;; Returning to top level loop.

(setq a nil)

NIL

(assoc 'r a)

NIL



The way tha newlisp automatically binds a newly referenced variable to nil is different from common lisp that requires a setq but the newlisp action is the more appropriate one for a language more targeted at scripting.

I believe that ISLISP (eg see http://christian.jullien.free.fr/">http://christian.jullien.free.fr/ ) even requires the variable name be bound using defglobal, let, for, or let* before it can be setq'ed to - for extra safety I guess.

eg:



C:openlisp>openlisp

;; OpenLisp v7.5.0 (Build: 3110) by C. Jullien [May  6 2003 - 18:45:55]

;; Copyright (c) 1988-2003.

...

? (setq a nil)

** setq : unbound-variable : a

? (defglobal a nil)

= a

? a

= nil

? (setq a nil)

= nil

?



Does alisp automatically bind new vars to nil?

Regards

Nigel
#408
Anything else we might add? /
November 23, 2003, 03:51:40 PM
Apologies for misconstruing your point.



Just regards the comment that Common Lisp gives an error - the Hyperspec says of assoc :

"Exceptional Situations:



Should be prepared to signal an error of type type-error if alist is not an association list. "

But the common lisp implementations CormanLisp 2.5 and Allegro CL 6.2, for example, accept nil as an association list (probably as nil and '() are treated the same in Common Lisp).

eg

;; Corman Lisp 2.5  Copyright © 2003 Corman Technologies. All rights reserved.

;; Licensed to Nigel Brown [version 2.0].

(assoc 'r '((a . b) (c . d) (r . x) (s . y) (r . z)))

(R . X)

(assoc 'r nil)

NIL

(assoc 'r "string")

;;; An error occurred in function ASSOC:



And Allegro CL

CG-USER(1): (assoc 'r nil)

NIL

CG-USER(2): (assoc 'r "string")

Error: Illegal argument to endp: "string"

[condition type: TYPE-ERROR]

CG-USER(3):



I guess it comes down to the newlisp philosophy that nil is not '() but perhaps they should be treated the same in usage like (assoc ?

(particularly if it has complicated porting) What do you think Lutz?



I presume alisp would throw an error if assoc-list is a string rather than nil.



Regards

Nigel
#409
Anything else we might add? /
November 23, 2003, 03:59:04 AM
assoc will work if assoc-list is the empty list () which is not the same as nil in newlisp

viz

newLISP v7.3.1 Copyright (c) 2003 Lutz Mueller. All rights reserved.



> (assoc 1 nil)



list expected in function assoc : nil



> (assoc 1 '())

nil

>

Perhaps the assoc-list's could be set to '() when set up



or if not, use (if to test for nil assoc-list



(if assoc-list (do-not-nil-stuff) (do-nil-stuff))



Regards

Nigel
#410
Anything else we might add? /
November 22, 2003, 01:33:49 AM
try a function defined using directory and regex say:



(define (files d f) (filter (lambda (x) (regex f x)) (directory d)))



usage would be lke (files "c:/temp/" "[Aa][a-z]+.txt")

that is first is the directory as a string the second is a regular expression as a string (not quite as friendly as filename wildcards but more powerful).

Filter works because will return nil if there is no match.



Regards

Nigel
#411
Anything else we might add? /
November 20, 2003, 03:52:07 PM
Sounds a good plan.

Questions - with newlisp being explicitly set to the C locale will this change any previous alignment between toupper and pcre regarding what is uppercase (I don't know how well aligned they were in the past without explicit locale setting but explicitly setting locale may change how toupper() handles 251 for example)

or more simply - does the explicit C locale differ from the current stable release behaviours



I could fiddle with examples to find this out but thought you might have the answers at your finger-tips.



Nigel
#412
newLISP in the real world /
November 19, 2003, 11:52:13 PM
An extensive discussion of perl locale use and issues is at:

http://www.perldoc.com/perl5.6/pod/perllocale.html">http://www.perldoc.com/perl5.6/pod/perllocale.html



An issue for newlisp is how to have the (upper-case and (regex.. working with the same locale. The pcre lib docs suggest that quite a bit of fiddling is needed (compiling custom tables for each desired charset) for pcre to be locale aware - otherwise upper case will mean different things to regex and upper-case.



Perhaps the standard newlisp could work with default locale (option(2) of Lutz's post) and a special compilation flag be used if a locale aware is desired. Looking at the perl locale discussion shows what a can of worms locale can open.



Nigel
#413
newLISP in the real world /
November 19, 2003, 05:44:01 PM
Sorry if my last post caused confusion - the variation in console fonts on win systems is the source of confusion

My above comments on the sqrt sign apply using "Lucinda ConsoleP" font on my DOSBox on my Win98SE setup - that has the sqrt sign as 251 - however I see noe that many fonts have

u-hat û at that value which is converted to uppercase by subtracting 32.

Also although my CommandPrompt box on WinXP Pro is set to Lucinda Console that 'should' have u-hat a line draw sumbol actually appears-



C:temp>newlisp

newLISP v7.3.5 Copyright (c) 2003 Lutz Mueller. All rights reserved.



> "251"

"¹"

> (upper-case "251")

"█"

>

(I note here 251 is ? superscript 1 and uppercases to a block)



Very confusing in the upper decimal characters.



Nigel

I guess the use of an unexpected display font will muddy the waters.
#414
newLISP in the real world /
November 19, 2003, 04:08:12 PM
Using the functions in the readme I noticed that the square root sign 251 is channged by upper-case.

Compare 7.3.3 which leaves sqrt sign alone:

newLISP v7.3.3 Copyright (c) 2003 Lutz Mueller. All rights reserved.



> (char "251")

251

> (char (upper-case "251"))

251

> (char (upper-case "a"))

65

> (char "a")

97

>

with 7.3.5 de novo that seems to subtract 32 to make it "uppercase":



C:temp>newlisp

newLISP v7.3.5 Copyright (c) 2003 Lutz Mueller. All rights reserved.



> (char "251")

251

> (char (upper-case "251"))

219

> (set-locale 0)

nil

>





I'm in Australia with Win XP Pro



Regards

Nigel
#415
newLISP in the real world /
November 19, 2003, 03:39:13 PM
My concern was that I'm doing a little awk-like implementation in newlisp and am using both read-line and multiple regex (on current-line or part thereof) mixed in the code.

I currently retrieve (current-line) a number of times per line read and apply regex various ways (the way awk steps through applying its pattern rules over and cver to the one line).

I couldn't see how having $0 for both current-line and regex use would work in that situation and am quite happy that $0 is used with regex and that current-line is not depreciated - perhaps it should stay that way.



I can see the logic for reusing a concept like $0 across various functions to aid programming but if it is used by functions that may be sprinkled through the one code fragment the nature of its current value becomes problematical (and could vary in nature depending on the program path taken to get to a particular point).



I would vote for keeping (current-line) as is.



Regards

Nigel



PS re manual typos - the syntax definition of (single ... reads (sin ... in the manual I have.
#416
newLISP in the real world /
November 18, 2003, 09:21:51 PM
Lutz

README_7305.txt is missing

Nigel
#417
newLISP in the real world / ? current-line depreciated
November 18, 2003, 08:20:42 PM
In the newlisp docs (manual v7.3.3) it says about current-line:

current-line

syntax: (current-line) deprecated use $0



However, $0 is used as a return variable from regex -

is the "deprecated use $0" a documentation error?

Regards

Nigel
#418
newLISP in the real world /
November 18, 2003, 03:13:23 PM
Further to my earlier reply: from the Borland helpfile BCB5.HLP

<quote>

Syntax



#include <locale.h>

char *setlocale(int category, const char *locale);

wchar_t * _wsetlocale( int category, const wchar_t *locale);



Description



Use the setlocale to select or query a locale.



Borland C++ supports all locales supported in NT 3.5x and Win95/NT 4.0 operating systems. See your system documentation for details.



The possible values for the category argument are as follows:



Value   Affect



LC_ALL   Affects all the following categories

LC_COLLATE   Affects strcoll and strxfrm

LC_CTYPE   Affects single-byte character handling functions. The mbstowcs and mbtowc functions are not affected.

<end quote>...

<quote>

To take advantage of dynamically loadable locales in your application, define _ _USELOCALES_ _ for each module. If _ _USELOCALES_ _ is not defined, all locale-sensitive functions and macros will work only with the default C locale.

<end quote>

This could be tried.

Regards

Nigel
#419
newLISP in the real world /
November 18, 2003, 06:20:42 AM
Hi Lutz,

I can imagine that trying to have consistency across platforms is tricky - probably for now just letting the FPU handle things internally is a reasonable position (although I don't know what the platform inconsistency implications of different FPUs that may be in, say, Solaris systems).

Re your questions -note I come from a float (largely workday stats /graphics) interest background

>(1) I have been asked for 64 bit integer support (currently 32 bit), the >LISP cell in newLISP has space for it (like for floats already), but not all >compilers on 32bit platforms suport it?

If its too hard to be consistent across platforms I'd stick to 32 for now



>(2) decimal based arithmetik: for people doing financial stuff dealing with >binary based arithmetik is alwaysa a hassle becuase of rounding errors, >not having it, excludes newLISP from a big segment of software.

Apart from Cobol and some specialised areas of Basic I don't know that it's really properly supported elsewhere much - look at discussions of use of

this type in Ada and you see that most implementations there are really just floats under it.



>(3) infinite precision integer arithmetik: I don't know much about it, but >see that some other languages are supporting it.

It looks cute to be able to calculate some big factorial or prime but outside number theory I don't know that there is much need for it - some of the complications in the maths of Common Lisps seem to come from the associated automatic type conversions between various big number

representations.



I'd be more interested in a complex type package being available before the integer side was upgraded - but that's just a personal interest and not likely to be commercially relevant.



As long as newlisp is competent and consistent in double size floats (as it is) I would see the rest as having the potential of bloating newlisp with little payback.



Regards

Nigel
#420
newLISP in the real world /
November 18, 2003, 03:19:24 AM
I found

http://mail.python.org/pipermail/python-dev/2000-May/004165.html">http://mail.python.org/pipermail/python ... 04165.html">http://mail.python.org/pipermail/python-dev/2000-May/004165.html

that discusses toupper conversion (in the context of C libraries in Python?)

viz:<quote>

> On POSIX systems there are a several environment variables used to

> control the default locale settings for a users session.  For example

> on my SuSE Linux system currently running in the german locale the

> environment variable LC_CTYPE=de_DE is automatically set by a file

> /etc/profile during login, which causes automatically the C-library

> function toupper('ä') to return an 'Ä' ---you should see

> a lower case a-umlaut as argument and an upper case umlaut as return

> value--- without having all applications to call 'setlocale' explicitly.

>

> So this simply works well as intended without having to add calls

> to 'setlocale' to all application program using this C-library functions.



I don;t believe that.  According to the ANSI standard, a C program

*must* call setlocale(LC_..., "") if it wants the environment

variables to be honored; without this call, the locale is always the

"C" locale, which should *not* honor the environment variables.

<end quote>



This suggests that newlisp code could have a locale setting that would lead to the correct conversion (if supported by borland)

I'm not currently at a computer with the borland compiler installed so haven't looked at the borland docs.

Regards

Nigel
Pages 1 ... 26 27 28 29