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 ... 25 26 27 28 29
#391
newLISP and the O.S. /
December 11, 2003, 07:03:28 PM
I've been playing with calling newlisp from IBASIC http://www.pyxia.com/ibasic.html">http://www.pyxia.com/ibasic.html and realised it would be good to be able to check the dll newlisp version from the calling program - I couldn't see a function for it -

something like (version) -> "newLISP v7.3.17 Copyright (c) 2003 Lutz Mueller. All rights reserved."

so (nth 1 (parse (version))) -> "v7.3.17".



Also re initialization of dll

Following advice

When the DLL is loaded it looks for an ini.lsp file in the same directory as the DLL and loads it if it exists.

I tried putting ini.lsp (and init.lsp) into the directory but nothing seemed to happen the ini.lsp was

(setq a "this is inited")

Loading ini.lsp with (load "ini.lsp") has the expected effect.





also re suppression of (print ) mentioned earlier in thread

(write-line ) put a line onto an open IBASIC console - I haven't

tested what happens without a console but it may give problems

similar to (print ) but on the other hand outputting to the IBASIC

console could be good.

The IBASIC program I use is just a simple read-eval-print loop viz:



def ins, outs :STRING

declare "newlisp",dllEvalStr(thestring:STRING),STRING



OPENCONSOLE



while 1

input ">",ins

if ins = ""

 goto doneit

endif

outs =  dllEvalStr( ins)

print "OUT:", outs

endwhile

label doneit

Print "Break - press key to end"

DO:UNTIL INKEY$ <> ""

CLOSECONSOLE

END



In summary

-can we get at version?

-how to in.lsp the dll?

-watch out for (write-line in dll



Nigel
#392
newLISP in the real world /
December 11, 2003, 04:57:00 PM
regarding the 7.3.17 manual comment:

While read-line will block until a newline character is received, read-buffer will block when less characters than specified are available



read-buffer will not block if the pipe has been closed with less than specified bytes

which can be seen from the fragment



> (read-buffer 3 'buf 10)

about to read

<read bytes: 8 >

8

> buf

" process"



above where the last 8 bytes from the closed pipe are available

and from



> (read-buffer 3 'buf 10)

about to read

<read bytes: 0 >

0

>



where no blocking occues but zero bytes are returned as available fron the closed pipe.



Perhaps docs should read:

read-buffer will block when less characters than specified are available from a pipe that has not had the writiing end closed by all processes.



Nigel





PS I've not looked at read-line blocking at all, particularly what happens if the pipe has been closed but without a newline.
#393
newLISP in the real world /
December 11, 2003, 04:35:46 PM
Further on (integer ) - it chokes aka "crashes" on too big a floating point

when used in the second sense of its definition

integer

syntax: (integer str [default-exp] )

syntax: (integer num [default-exp] )

viz

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



> (integer 3.5)

3

> (integer 1e8)

100000000

> (integer 1.5e8)

150000000

> (integer 1e20)





Probably relates to "math exception handling" thread

http://www.alh.net/newlisp/phpbb/viewtopic.php?t=102">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=102



?unless the big number is infinity

Interestingly +INF converts to 0 with (integer ) viz



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



> (float 3.5)

3.5

> (float 1e600)

+INF

> (setq infinity 1e600)

+INF

> (integer infinity)

0

> infinity

+INF

>



Apologies for stressing out newlisp with all these funny numbers.



Nigel
#394
newLISP in the real world / (abs ) crash with NaN
December 11, 2003, 04:18:38 PM
Giving newlisp 7.3.17

(abs (sqrt -1))

crashes newlisp -

so does

> (setq isnan (sqrt -1))

+NAN

> (NaN? isnan)

true

> (abs isnan)



I note in nl-math.c some code protects DIVIDE from Nan viz

#ifdef __BORLANDC__

         if(isnan(number))

            {

            result = number;

            break;

            }

#endif

         if(number == 0.0)

            return(errorProc(ERR_MATH));

         result /= number;

         break;



but not other functions

so (min (sqrt -1) 2) also "crashes".



I suspect it may relate to uncaught signals or exceptions from the math processor along the lines of the thread "math exception handling" http://www.alh.net/newlisp/phpbb/viewtopic.php?t=102">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=102



I've not tested all functions as to susceptibility to NaN problems - you

can probably see from the code which ones are at risk. In leu of catching

the signals etc perhaps more checking for NaN along the lines above used for divide is needed for robustness.



Nigel
#395
newLISP in the real world /
December 11, 2003, 01:23:14 PM
Further regarding integer conversion

Q:What should (integer ) be doing at the extremes?

I find:



> (integer "-2147483648")

-2147483648

> (integer "-2147483649")

2147483647

> -2147483649

-2147483648

>

That is, newlisp truncates it integers that are too negative (as is stated in the docs) while (integer ) wraps around to positive.

At  it says of strtoul at Linux Programmers manual ( http://unixhelp.ed.ac.uk/CGI/man-cgi?strtoul+3">http://unixhelp.ed.ac.uk/CGI/man-cgi?strtoul+3 )

RETURN VALUE

       The  strtoul()  function    returns either the result of the

       conversion or, if there was  a  leading   minus  sign,  the

       negation of the result of the conversion, unless the orig-

       inal (non-negated) value would  overflow;  in  the  latter

       case,  strtoul()    returns  ULONG_MAX  and  sets the global

       variable errno to ERANGE.

So the truncation to maximun seems correct behaviour rather than wrapping to positive. I don't have the Borland docs at this workstation to check their strtoul return info.







Also re (integer ) docs - they need to be corrected to be in line with changed behaviour:



The integer docs 7.3.17 still say "str must start with a number digit"

(integer "123")          => 123

(integer " 123")         => nil

while newlisp now does  



> (integer "   123")

123

>



Regards

Nigel
#396
newLISP newS /
December 11, 2003, 05:58:25 AM
In 7.3.17 Function Reference:

"bool

true, nil, or expressions evaluating to true or nil.

true, nil, (X <= 10)"

 example should be (<= x 10)



Nigel
#397
newLISP and the O.S. /
December 08, 2003, 01:26:11 PM
re: as long as pointers and integers have the same byte width their optimizations will not hurt



Some discussions on the optimizations suggest there may more importantly be an issue about what word boundries are used when allocating/using pointers vs integers (? that may be effected more by sizes of what is packed around them rather than their own size)

 - there was also a concern voiced that turning off warnings but not the optimizations may disable a more useful warning case down the track.

Although overall this is not a big issue I'd guess.



Nigel
#398
newLISP and the O.S. /
December 07, 2003, 06:34:47 PM
I see at http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=86.topic">http://pub26.ezboard.com/ftichessteamhq ... D=86.topic">http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=86.topic

the discussion includes these rules and, in part, observes

 Re: GCC 3.3 prerelease for TIGCC

--------------------------------------------------------------------------------

 Those are the stupid strict-aliasing rules.  I knew there was some TIGCC code breaking them. And what's the worst: while the warning is new, the fact that the optimizer might break some code you get warnings about now was already there since GCC 3.0. As for fixes:

- the quick and dirty fix is to use -Wno-strict-aliasing to get rid of the warnings

- the quick and less dirty fix is to use -fno-strict-aliasing to get rid of the warnings and of the risky optimizations

- the clean fix will be to add __attribute__((may_alias)), a new attribute in GCC 3.3, to some of the TIGCCLIB types. The structure used to define INT_HANDLER is one of them, HSYM is another one (to make sure my *(unsigned long*)&hsym hack works).



Nigel
#399
newLISP in the real world /
December 07, 2003, 04:04:31 PM
Keep in mind that regrading leading + or spaces with number?

a leading + is not valid

eg

> (number? "+12")

nil

> (number? "-12")

true

>



I also noticed that the definition of what (integer ) will accept is not

quite the same as strtoul as strtoul will accept leading spaces while

(integer ) will not (that leading spaces are not allowed is stated in the manual)

viz

> (number? " 12")

nil

> (integer "     12")

nil



Borland says of strtol regarding leading whitespace (strtoul uses same rules) :

...the characters must match this generic format:



   [ws] [sn] [0] [x] [ddd]



where:



[ws]   =   optional whitespace

[sn]   =   optional sign (+ or -)

[0]   =   optional zero (0)

[x]   =   optional x or X



[ddd]   =   optional digits

...



Possibly for user input you may wish to accept leading spaces - but

perhaps you skip over this already.



Just a couple of points to bear in mind.

Nigel
#400
newLISP newS /
December 07, 2003, 03:30:39 PM
Correction:

in Input/output and file operations (7.3.16) the list has

device twice - the second should be exec.



Request:

Could the newlisp-tk manual be available as .pdf too.



Nigel
#401
newLISP in the real world /
November 28, 2003, 10:49:56 PM
Hi,

I found the reason that the read was blocking was that although the process had closed 4 the original newlisp still had it open! Closing 4 in the program that is reading from 3 fixed the blocking viz:

> (pipe)

(3 4)

> (process "./newlisp dothis.lsp 3 4")

true

> (close 4)

true

> (read-buffer 3 'buf 10)

about to read

<read bytes: 10 >

10

> buf

"hello from"

> (read-buffer 3 'buf 10)

about to read

<read bytes: 8 >

8

> buf

" process"

> (read-buffer 3 'buf 10)

about to read

<read bytes: 0 >

0

>



The "about to read" and "read bytes:" are from some debug printf's I used to see what was happening.

What put me on to the problem was this explaination from http://www.opengroup.org/onlinepubs/007908799/xsh/read.html">http://www.opengroup.org/onlinepubs/007 ... /read.html">http://www.opengroup.org/onlinepubs/007908799/xsh/read.html::

"When attempting to read from an empty pipe or FIFO:



If no process has the pipe open for writing, read() will return 0 to indicate end-of-file.



If some process has the pipe open for writing and O_NONBLOCK is set, read() will return -1 and set errno to [EAGAIN].



If some process has the pipe open for writing and O_NONBLOCK is clear, read() will block the calling thread until some data is written or the pipe is closed by all processes that had the pipe open for writing. "

<note last paragraph>

It also lines up with advice from the book "Linux programming by example" by Kurt Wall that points out:

"The general rule is that the reader process closes the write end of the pipe and the writer process closes the reader end of the pipe."

by the way dothis.lsp was:

(close 3)

(write-buffer 4 "hello from process" )

(close 4)

(exit)



Hope this serves as a tip for anyone else new to trying out pipes.



Nigel
#402
newLISP in the real world /
November 27, 2003, 08:27:59 PM
(Apologies if this is sounding more like a blog than a thread)



I will try properly/gracefully closing the pipe from the dothis.lsp end - I was

thinking that program termination would do that but perhaps not.

I'll report back once I've had access to a linux system.



Nigel
#403
newLISP in the real world /
November 27, 2003, 01:58:47 PM
No, it seems to wait too:

[nigel@p1300 newlisp_7303]$ newlisp

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



> (setq pipes (pipe))

(3 4)

> (process "./newlisp dothis.lsp 3 4")

true

> (setq replied (read-line 3))

"hello from process"

> (setq rep2 (read-buffer 3 'buffer 10))



I'm using Mandrake 9.1



Any way of testing pipe to see if input is there?

I want to set a number of processes on potentially long tasks and check for replies.

Hopefully once I get my Quantian (http://dirk.eddelbuettel.com/quantian.html">http://dirk.eddelbuettel.com/quantian.html) OpenMosix cluster (home hobby cluster) running

then the processes will distribute across the cluster when running.

If I can't manage them with straight reads then I'll have to think of fancier coordination.



Nigel
#404
newLISP in the real world /
November 27, 2003, 01:33:12 PM
In answer to my own question it looks like

(read-buffer will do it?

Nigel
#405
newLISP in the real world /
November 27, 2003, 12:37:48 PM
Thanks Lutz.



Trying it works fine

but if my process has exited and the original process does another read-line from that

pipe it sits waiting (?forever) - is there a way of testing the pipe for data without

going into a blocking wait?



Regards

Nigel
Pages 1 ... 25 26 27 28 29