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 - c.ln

Pages1

newLISP and the O.S. /

June 07, 2006, 06:55:37 AM

Thanks a lot for your answers.

HPW, the Borland 2006 Studio comes with a Pascal, a C++ & a C# compilers and build executables both for Win32 & .NET ...

I use it since several years ( Turbo Pascal 1.2 :-)

The make with MinGW environment is easy, but the dbg tool against td32 or the integrated debugger in the Borland IDE is awfull. If you want to enter in the code to understand it and even to modify it, it's better to use frendly and powerfull tools.

Best regards,

Christian

newLISP and the O.S. / Compiling newLisp-8.8.0 with Borland C++ builder 2006

June 06, 2006, 04:25:55 PM

Hello Lutz !

As i try to compile the source of newLisp with Borland ( in a project ), the compiler detect one bug on the line n° 340 of nl-math.c in function:

CELL * functionFloat (CELL * params, int op)

{

...

switch (op)

{

...

case OP_ERRORFUNC: floatN = erf (floatN); break;

...

the function:

double erf (double) is undefined

The closest function name that i find is p_erf but the signature is complitely different, there is a link in file "primes.h" between erf & p_erf in the table named primitive.

In the hope that these few lines can help you,

Best Regards,

Christian

PS

I keep hope alive that one day, you introduce struct access for complex data ( records ) which permit field access without pack & unpack the buffer in several variables and without compute offset & length for the atomic datas.

newLISP newS / where is the download for newlisp-blog ?

June 06, 2006, 03:57:35 PM

Thanks alot for this link !

Regards,

Christian

newLISP newS / where is the download for newlisp-blog ?

March 28, 2006, 02:49:56 PM

Hi Lutz !

The last time i have downloaded the newlisp-blog, it was the 28-07-2005 and the version number was 3.9;

Did you stop this sample/product ? I can't find the link for update the blog.

Best regards,

Christian

Anything else we might add? / begin of observation round :)

October 18, 2004, 06:37:28 PM

ok Lutz !

you have your mountains to climb, and i have to learn newLisp concept & implementation (to evalutate its rating :)

i take in my mind the pb of multi-threading.

the first idea which come to me, if your problem is the shared memory area, is to use win32 API memory function to allocate separate Heap for each Thread:

- GlobalAlloc(), GlobalRealloc(), etc ...

- LocalAlloc(), LocalRealloc(), etc ... (same effects under Zidowz)

- HeapCreate(), HeapAlloc(), etc ... (is more intersting if you do more than one globaAlloc for each thread)

- in conjunction with GetProcessHeaps() to retreive the Handles.

my question is what kind of fork do you need ?

- multi-processing (CreateProcess() Win 32 API)

or

- multi-threading (CreateThread() Win 32 API)

standard Unix fork() is more similar to the first option, but under Zindowz, the second option is more powerful.

do you imagine newLisp Tree and Threads branches or newLisp Forest ?

and what kind of newLisp syntax will permit to insert multi tasking ?

i must warn you, that cygWin is trying to be Posix compliant, that is a complication and not usefull to run a program for a Zindowz target.

thanks for the attention i require from you.

cordially,

Christian

Anything else we might add? / speed & style ...

October 18, 2004, 07:46:46 AM

thanks (a lot) Lutz for your help !

but (i understand that you don't see it) in the sample code i wrote in the penultimate mail, an only ONE memoryAlloc is performed for an infinite reading (as long as you use the same buffer with the same size, what is frequent when you read fixed size records), i avoid too the memset () & memcpy () which are unutil.

the redondant/unutil declaration of CELL_xxx are only here for best understanding of the code, and beleive me, pushing 4 integers/pointers further on the stack increase loop performance about 0.0000000000000001 % :) against re-reading/understanding the source.

of course we could use the same variable "params" to access to the different cells, but if you unassemble code generate by using this kind of variables (using parameters as variables) you will see that the code generated is less compact/performant that using real local variables, it's due that the compiler makes differents assumes for this two different kinds of variables (the principal is parameter variable can' t be a complete register variable (elemantary, my dear Dr Watson :)).

if i understand your last message, i'm in front of 2 choices:

- i rewrite the entire unit of nl-filesys.

- i keep the style of the precedent author for modifying pieces of routines.

but what is the precedent style ?

where are the standard comment(s) for each functions ?

and if i take the first option, what style writing source will be a help or an amelioration of the precedent ? (to implement my style is not necesserally a good idea, except for who like mosaic style, lol)

don't beleive i would give a lesson, my intentions are to give some help and to participate/contribute to that project.

for the help documentation of which i need, is

- the documentation of the basics structures like CELL, SYMBOL, etc ...

- the use/type casting of their fields like aux, contents, etc ...

- the general assumes/principes for what a CELL represent and their organization.

what ever, i'm going to propose a rereading for this unit in the next weeks (time is sharing between my job, wy wife, my children, my sport, ... and newLisp, lol :)

cordially,

Christian

Anything else we might add? / 1 mistake and current code for p_readBuffer in nl-filesys.c

October 15, 2004, 12:18:00 PM

is there a team developpers for newLisp ?

i will be very happy if i can have more informations to understand the code,

conceptual principles for the basic structures and their links with the newLisp script syntaxe.

cordially,

Christian

typedef unsigned char uchar;

and not

typedef unsigned char * uchar;

the original code which was rearranged in the precedent message.

CELL * p_readBuffer(CELL * params)

{

int handle, size;

int bytesRead;

unsigned char * buffer;

unsigned char * buff;

CELL * strCell;

SYMBOL * readSptr;

params = getInteger(params, (UINT*)&handle);

params = getSymbol(params, &readSptr);

getInteger(params, (UINT*)&size);

if(isProtected(readSptr->flags))

return(errorProcExt2(ERR_SYMBOL_PROTECTED, stuffSymbol(readSptr)));

buffer = allocMemory((int)size+1);

memset(buffer, 0, (int)size+1);

if((bytesRead = read(handle, buffer, size)) == -1)

{

free(buffer);

return(nilCell);

}

buff = allocMemory((int)bytesRead+1);

memcpy(buff, buffer, bytesRead);

*(buff + bytesRead) = 0;

freeMemory(buffer);

strCell = getCell(CELL_STRING);

strCell->aux = bytesRead + 1;

strCell->contents = (UINT)buff;

deleteList((CELL *)readSptr->contents);

readSptr->contents = (UINT)strCell;

return(stuffInteger(bytesRead));

}

Anything else we might add? / look'n for the code

October 15, 2004, 11:56:14 AM

Because i was afraid of to have 3 copies of my data before working and three others ones to save that job, i take a look more attentive on the source, specially for the p_readBuffer function.

Still yet, sources of newLisp only serve to compile under cygWin... :)

I was very surprised to see that 2 allocMemory, 1 memset, 1 memcpy, 2 freeMemory, 1 deleteList were made for each call.

The code located below is not tested, it's only for discuss.

The documentation of the source is very brief, so i beg your pardon for conceptual mistakes.

The principal purpose of these trial, is to reuse the allocated data and to avoid heap management which is always a source of retard.

The dots before statements are for prevent trim strings parsed by this editor.

A fixed police will be a best for reading too.

//newLisp syntaxe: ( read-buffer int-file sym-buffer [ int-size ])

//params= list of CELL ( CELL-intFile CELL-symBuffer CELL-intSize )

//result= nilCELL or newCELL-nbrBytesRead

//function actions

//- getParams && #ifdef _SAFETY_ checkParams #endif :)

//- (re)formate/keep alive CELL-symBuffer

//- perform read on handle into buff

//- return expected result ( as possible :)

typedef

unsigned char.....* uchar;

CELL..............* p_readBuffer........(

..CELL..............* params )

{

CELL..............* CELL_intFile,

..................* CELL_symBuffer,

..................* CELL_intSize,

..................* CELL_dummy;

int.................handle............= -1,

....................size;

int.................bytesRead;

uchar.............* buff..............= NULL;

CELL..............* strCell...........= NULL;

SYMBOL............* readSptr..........= NULL;

CELL_intFILE......= params;

#ifdef _SAFETY_

if ( ! CELL_intFile || CELL_intFile == nilCell )

..return ( errorProcArgs ( ERR_MISSING_ARGUMENT, params ));

#endif

CELL_symBuffer....= getInteger ( CELL_intFILE, ( UINT * ) &handle );

#ifdef _SAFETY_

if ( ! CELL_symBuffer || CELL_symBuffer == nilCell )

..return ( errorProcArgs ( ERR_MISSING_ARGUMENT, params ));

#endif

CELL_intSize......= getSymbol ( CELL_symBuffer, &readSptr );

//this part may be discuss as read-buffer could be called on an anonymous (unreferenced) buffer

#ifdef _SAFETY_

if ( ! readSptr || readSptr == nilSymbol )

..return ( errorProcArgs ( ERR_SYMBOL_EXPECTED, params ));

#endif

if ( isProtected ( readSptr->flags ))

..return ( errorProcExt2 ( ERR_SYMBOL_PROTECTED, stuffSymbol ( readSptr )));

strCell = ( CELL * ) readSptr->contents;

if ( strCell )

{

..if ( strCell->type != CELL_STRING )

..{

....readSptr..........->contents..........= ( UINT ) nilCell;

....deleteList ( strCell );

....strCell...........= NULL;

..}

..else

....buff..............= ( uchar * ) strCell->contents;

}

if ( ! CELL_intSize || CELL_intSize == nilCell )

{

#ifdef _SAFETY_

..if ( ! strCell )

....return ( errorProcArgs ( ERR_MISSING_ARGUMENT, params ));

#endif

..size..............= strCell->aux - 1;

#ifdef _SAFETY_

//optional check, ( read handle buff 0 ) may be used/util ?

..if ( ! size )

....return ( errorProcArgs ( ERR_INVALID_PARAMETER_0, params ));

#endif

}

else

{

..CELL_dummy........= getInteger ( CELL_intSize, ( UINT * ) &size );

#ifdef _SAFETY_

..if ( CELL_dummy != NULL )

....return ( errorProcArgs ( ERR_EXTRA_ARGUMENT, params )); // a new one, lol :)

#endif

..if ( strCell && size != strCell->aux - 1 )

..{

....freeMemory ( buff );

....buff..............= NULL;

..}

}

if ( ! buff )

..buff..............= allocMemory ( size + 1 );

if ( ! strCell )

..strCell...........= getCell ( CELL_STRING );

strCell...........->aux...............= size + 1;

strCell...........->contents..........= ( UINT ) buff;

readSptr..........->contents..........= ( UINT ) strCell;

if (( bytesRead = read ( handle, buff, size )) == -1 )

{

//make an empty string AZT

..* buff............= 0;

..return ( nilCell );

}

//make a string AZT

* ( buff + bytesRead ) = 0;

// create a new CELL with bytesRead in field contents

return ( stuffInteger ( bytesRead ));

}

Thanks for all people who are so courageous to read this mail ! :)

Cordially,

Christian

Anything else we might add? / Did i understand Lutz explanation ?

October 14, 2004, 04:37:29 PM

if i understand the explaination(s) of Lutz, to access to my data, i need 3 copies of them: ('rec; 'lst; 'fld).

is it possible to implement a syntaxe like 'rec.fld to access more quickly to the data ?

recType could be declare as list of 'fldAttr (fldName

,fldOffset // 0= calculate from (previous fldOffset fldSize)

,fldType

[, fldSize])

fldType could be declare as list of 'valAttr (size //0= must be specified

,readable

,writable

,recType //if any to find common subStructures

,context //if any to find context:methods,functions,constants for fldType

,...)

//pseudo declaration of type char

(constant 'char (cons 0 true true nil 'CHRFONC))

//pseudo declaration of type rec_lotSynergie

(constant 'rec_lotSynergie (cons ((cons 'a 1 'char 7) (cons 'cod_EDS 1 'char 3) (cons 'cte_4 0 'char 1) (cons 'dat_lotQQQ 0 'char 3)))

//read data from flux previously open

(read-buffer handle 'buff 'rec_lotSynergie.size)

//pseudo access to a field

(set 'qqq ((rec_lotSynergie buff).dat_lotQQQ)))

or

(set 'lotSynergie (rec_lotSynergie buff))

(set 'qqq ('lotSynergie.dat_lotQQQ))

like you can read, i do not hesitate to transtype a newLisp data referenced by the symbol 'buff ! lol

forgive me for all the atrocities i write, i'm a newBee in Lisp & newLisp (for the blinds who do not see that :)

cordially,

Christian

#10

Anything else we might add? / deep in the details

October 13, 2004, 03:07:07 PM

You wil find behind this text, a fragment of interface unit.

This interface declare 3 types of record which may be founded in a sequential file. Typically, we have the following sequence:

deblotSimac

remiseSimac

chequeSimac

chequeSimac

chequeSimac

...

remiseSimac

chequeSimac

chequeSimac

chequeSimac

...

deblotSimac

...

and so on

This kind of file is ascii file, (except for cr/lf at each end of record)

Standard actions on this kind of file is

to verify

integrity of fields (by tables or by key computing),

integrity of sequence.

to inject or modify some fields.

to identify double references and so on.

to merge or split multiples sources.

If i create from external call list like HPW (Horse PoWer :) suggest me, i'm not sure that it is the best form to manipulate datas.

Imagine that i expose is trivial exercise, next steps brass multiple flux/streams to produce new ones.

A constraint is input files and output files must keep ASCII encoding.

Well, i hope that i'm not too boring, and i'm grateful for the help you give me !

Cordially

Christian

(***********************************************************)

unit dclSimac2;

(***********************************************************)

interface

(***********************************************************)

uses

utypes,

utypchar,

utypbyte,

utypdate,

stddcl;

(***********************************************************)

const

cod_debLotSimac= '1';

cod_remiseSimac= '2';

cod_chequeSimac= '3';

(***********************************************************)

type

rec_lotSynergie = packed record

case byte of

1: ( a : _a7char );

2: ( cod_EDS : _a3char;

cte_4 : char;

dat_LotQQQ : _a3char );

end;

(***********************************************************)

type

ptr_debLotSimac = ^rec_debLotSimac;

rec_debLotSimac = packed record

//cte_aZero ,

//cod_enreg : char; (* code enregistrement *)

num_lotSyn : rec_lotSynergie;

num_remise : _a7char;

dat_numeriz : rec_jjmmssaa;

tim_telecol : rec_hhmm;

cod_agence : _a5char;

cod_scanner : _a4char;

nbr_remises ,

nbr_cheques : _a5char;

mtt_totLot : rec_montantVfix;

buf_z4 : _a7char;

buf_z3 ,

buf_z2 : _a12char;

buf_z1 : rec_montantPack;

num_image : _a12char;

cod_valid : _a2char;

cod_deviz : char;

end;

(***********************************************************)

type

ptr_remiseSimac = ^rec_remiseSimac;

rec_remiseSimac = packed record

//cte_aZero ,

//cod_enreg : char; (* code enregistrement *)

num_lotSyn : rec_lotSynergie;

num_remise : _a7char;

dat_numeriz : rec_jjmmssaa;

tim_telecol : rec_hhmm;

nbr_cheques : _a5char;

mtt_remise : rec_montantVfix;

cpt_remise : _a11char;

buf_z4 : _a7char;

buf_z3 ,

buf_z2 : _a12char;

buf_z1 : rec_montantPack;

fil_01 : _a3char;

num_image : _a12char;

cod_valid : _a2char;

cod_deviz : char;

end;

(***********************************************************)

type

ptr_chequeSimac = ^rec_chequeSimac;

rec_chequeSimac = packed record

//cte_aZero ,

//cod_enreg : char; (* code enregistrement *)

num_lotSyn : rec_lotSynergie;

num_remise : _a7char;

mtt_cheque : rec_montantVfix;

buf_z4 : _a7char;

buf_z3 ,

buf_z2 : _a12char;

buf_z1 : rec_montantPack;

cod_banque : _a5char;

fil_01 : _a3char;

cle_RLMC : _a2char;

fil_02 : _a21char;

num_image : _a12char;

cod_valid : _a2char;

cod_deviz : char;

end;

(***********************************************************)

type

rec_imgSimac = packed record

cte_aZero : char;

case cod_enreg : char of

cod_debLotSimac : ( debLot : rec_debLotSimac );

cod_remiseSimac : ( remise : rec_remiseSimac );

cod_chequeSimac : ( cheque : rec_chequeSimac );

end;

type

ptr_Simac = ^rec_Simac;

rec_Simac = packed record

case byte of

1: (carte : rec_carte118); (* repr,sentation "physique" *)

2: (image : rec_imgSimac); (* repr,sentation "logique" *)

end;

(***********************************************************)

procedure init_Simac (var enr: rec_Simac; cod: char; pad: char = ' ');

(***********************************************************)

#11

Anything else we might add? / HowTo using record structure in newLisp

October 12, 2004, 03:01:06 PM

I have several lists of records to manage (thousands of thousands). These records form regular sequences through sequential process.

In the past, even in the present, i use C or Pascal to do it. But is it possible that LISP in the "ethymologie" (french word) could be a better choice ?

I am very impressed by the apparent facility of these script language, but when i do an overview of the documentation, i don't see anything about that (record/struct/union field type/length declaration).

Is it possible to manipulate elementary structure as a pseudo dotted pair ?

car = nameOfField, cdr = dataOfField of a list of pair which should be the record ?

I don't see advanced file functions like sharing, locking, etc...

Even if i call the Windows API to supply that, i need to utilize the result in a way that newLisp can manipulate.

Thanks beforehand for my naive questions !

Pages1

newLISP Fan Club

News:

Show posts

Messages - c.ln

newLISP and the O.S. /

newLISP and the O.S. / Compiling newLisp-8.8.0 with Borland C++ builder 2006

newLISP newS / where is the download for newlisp-blog ?

newLISP newS / where is the download for newlisp-blog ?

Anything else we might add? / begin of observation round :)

Anything else we might add? / speed & style ...

Anything else we might add? / 1 mistake and current code for p_readBuffer in nl-filesys.c

Anything else we might add? / look'n for the code

Anything else we might add? / Did i understand Lutz explanation ?

Anything else we might add? / deep in the details

Anything else we might add? / HowTo using record structure in newLisp