From: !!VV
Subject: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <1177553124.589692.245610@o40g2000prh.googlegroups.com>
Hello,


I'm struggling for my making first multi-file application.

I'm looking for instant nirvana for this:
 --> Make a package, having a func say hw ==> (print "hello world")
 --> use this in another 'main' file.
 --> lispworks steps ( adding package directory etc ) for this.


I'm wading through documentation, however a kickstart will be
appreciated (-:

--
!!VV  ==> http://notnotVV.blogspot.com

From: Ken Tilton
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <_pUXh.257$27.205@newsfe12.lga>
!!VV wrote:
> Hello,
> 
> 
> I'm struggling for my making first multi-file application.
> 
> I'm looking for instant nirvana for this:
>  --> Make a package, having a func say hw ==> (print "hello world")
>  --> use this in another 'main' file.
>  --> lispworks steps ( adding package directory etc ) for this.
> 
> 
> I'm wading through documentation, however a kickstart will be
> appreciated (-:

In the first file you load, have:

(defpackage #:my-first-package
    (:nicknames #:pkg1)
    (:use #:common-lisp)
    (:export #:my-first-function))

(in-package :pkg1)

(defun my-first-function yada yada

In the second file:

(in-package :pkg1)

(defun my-first-caller ()
    (my-first-function))

If you want the second file to be a diff package, do a defpackage there 
of my-second-package, have it :use the first pkg, then have the 
in-package form for the second package and you can reference the first 
function.

To load multiple file projects semi-painfully use mk::defsystem or ASDF.

kt

-- 
http://www.theoryyalgebra.com/

"Algebra is the metaphysics of arithmetic." - John Ray

"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts

"Stand firm in your refusal to remain conscious during algebra."
    - Fran Lebowitz

"I'm an algebra liar. I figure two good lies make a positive."
    - Tim Allen
From: Kent M Pitman
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <u1wi7ye7v.fsf@nhplace.com>
Ken Tilton <···@theoryyalgebra.com> writes:

> In the first file you load, have:
> 
> (defpackage #:my-first-package
>     (:nicknames #:pkg1)
>     (:use #:common-lisp)
>     (:export #:my-first-function))

I recommend breaking the above form off into a separate file.  Anyone
who uses this package might want to be able to load the package
definition, even people not planning to call the functions.  For example,
someone wanting to process the symbols in the other files.  Or someone
planning to define different definitions for the same package (not that
I particularly recommend that).

The informal convention on the Lisp Machines was that every "system"
(approximately, what CL calls a "compilation unit" and what the OP
here thinks of as a set of files) had a pkgdcl.lisp that was just that
package declaration.

Having done this, you can then do
 (mapcar #'load '("pkgdcl.lisp" "my-defs.lisp" "my-callers.lisp"))
but you can also break things up differently.

> (in-package :pkg1)
> 
> (defun my-first-function yada yada
> 
> In the second file:
> 
> (in-package :pkg1)
> 
> (defun my-first-caller ()
>     (my-first-function))
> 
> If you want the second file to be a diff package, do a defpackage
> there

or in a separate file, again,

> of my-second-package, have it :use the first pkg, then have the
> in-package form for the second package and you can reference the first
> function.
> 
> To load multiple file projects semi-painfully use mk::defsystem or ASDF.

semi-painfully? As upposed to fully painfully? Hmmm.
From: Ken Tilton
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <jWVXh.47$RM7.38@newsfe12.lga>
Kent M Pitman wrote:
> Ken Tilton <···@theoryyalgebra.com> writes:
> 
> 
>>In the first file you load, have:
>>
>>(defpackage #:my-first-package
>>    (:nicknames #:pkg1)
>>    (:use #:common-lisp)
>>    (:export #:my-first-function))
> 
> 
> I recommend breaking the above form off into a separate file.  Anyone
> who uses this package might want to be able to load the package
> definition, even people not planning to call the functions.

Kind of an edge concern, don't you think? Should we scare noobs with 
those? And I do not program that way.. maybe if one of the six people 
using Cells asked for that, otherwise....


>  For example,
> someone wanting to process the symbols in the other files.  Or someone
> planning to define different definitions for the same package (not that
> I particularly recommend that).
> 
> The informal convention on the Lisp Machines was that every "system"
> (approximately, what CL calls a "compilation unit" and what the OP
> here thinks of as a set of files) had a pkgdcl.lisp that was just that
> package declaration.
> 
> Having done this, you can then do
>  (mapcar #'load '("pkgdcl.lisp" "my-defs.lisp" "my-callers.lisp"))
> but you can also break things up differently.

Add a remove-if there is a fasl with a more recent date and you have 
ASDF beat.

> 
> 
>>(in-package :pkg1)
>>
>>(defun my-first-function yada yada
>>
>>In the second file:
>>
>>(in-package :pkg1)
>>
>>(defun my-first-caller ()
>>    (my-first-function))
>>
>>If you want the second file to be a diff package, do a defpackage
>>there
> 
> 
> or in a separate file, again,
> 
> 
>>of my-second-package, have it :use the first pkg, then have the
>>in-package form for the second package and you can reference the first
>>function.
>>
>>To load multiple file projects semi-painfully use mk::defsystem or ASDF.
> 
> 
> semi-painfully? As upposed to fully painfully? Hmmm.
> 

Fully painfully is clipping in OpenGL. Semi-painful is ASDF.

I assumed the noob was also interested in project management given the 
multi-file thing, and I guessed wildly they were not lucky enough to be 
using the AllegroCL Project Manager, so I wanted to recommend the most 
automated things available, but I also wanted to make clear that ASDF, 
well, is not all that user-friendly. It's only recommendation is 
ubiquity, and, once conquered, will however awkwardly provide 
push-button builds.

kxo


-- 
http://www.theoryyalgebra.com/

"Algebra is the metaphysics of arithmetic." - John Ray

"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts

"Stand firm in your refusal to remain conscious during algebra."
    - Fran Lebowitz

"I'm an algebra liar. I figure two good lies make a positive."
    - Tim Allen
From: Kent M Pitman
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <u7irzsku8.fsf@nhplace.com>
Ken Tilton <···@theoryyalgebra.com> writes:

> Kent M Pitman wrote:
> > Ken Tilton <···@theoryyalgebra.com> writes:
> >
> > I recommend breaking the [package declaration] off into a separate
> > file.  Anyone who uses this package might want to be able to load
> > the package definition, even people not planning to call the
> > functions.
> 
> Kind of an edge concern, don't you think? Should we scare noobs with
> those? And I do not program that way.. maybe if one of the six people
> using Cells asked for that, otherwise....

Novices needn't understand the rationale, only the instruction to do the
dogmatic action.  The rationale is offered not to convince them, nor to
make a case this will happen to them, but to give them the info they need
later to accommodate situations they might not have expected and/or to 
give up your rule when they've outgrown it.

My experience and the pitfalls I've seen may also be harsher than
yours because on Lisp Machines, files wanted to cache information on
the plist of the symbols, saying where the symbol is defined.  But
there's a chicken/egg problem if the definition of the symbol is in
the file you've read in, and it gets messy quickly because the file
has to either get executed in order to edit itself or else you have to
execute part of the file and then ask to have the buffer reparsed.
Having the package definition outboard simplifies the problem a lot,
by reducing the risk that the package declaration won't have been seen
already and/or by increasing the viability of loading someone's
package declaration without getting into loading lots of junk you
don't want.  So, in sum, you may be accidentally relying on artifacts
of your environment when you assume there are no such interactions.
People are used to considering the dependencies of things they do on
things happening, but often oblivious to their having relied on
something NOT having happened...

I was taught this rule early on, and it has served me well.  That's why
I shared it.  I cringe any time I see a package declaration in the same 
file as another form.  It can be done, sure.  But it's an automatic red
flag and I've just personally seen it lead to trouble often enough that
I somewhat tire of explaining why it's a red flag.  ... Conversely, I
don't find it hard to explain why they should be separated because 
"it sometimes causes problems that way" is honest, helpful, and easily
accepted.

> > Having done this, you can then do
> >  (mapcar #'load '("pkgdcl.lisp" "my-defs.lisp" "my-callers.lisp"))
> > but you can also break things up differently.
> 
> Add a remove-if there is a fasl with a more recent date and you have
> ASDF beat.

Indeed, instead of load, a better function should be used that does all
of that, yes.  I have my own source control system, and indeed it does 
that extra hair.

Mine unifies defsystem with a loader, in a manner reminiscent of Java.
(It is quite prescriptive about how to lay out your directories, too.)
I've contemplated publishing it for others to use, but haven't gotten
around to working out the details of that.  There are some tricky issues,
but the priority of doing so has been going up recently for me, so we'll
see.  It would certainly be more to talk about than mapcar of load.

> Fully painfully is clipping in OpenGL. Semi-painful is ASDF.
> 
> I assumed the noob was also interested in project management given the
> multi-file thing, and I guessed wildly they were not lucky enough to
> be using the AllegroCL Project Manager, so I wanted to recommend the
> most automated things available, but I also wanted to make clear that
> ASDF, well, is not all that user-friendly. It's only recommendation is
> ubiquity, and, once conquered, will however awkwardly provide
> push-button builds.

Thanks for the reviews.  Since I live in my own little self-constructed
universe of tools, I don't get a lot of cause to go playing with the 
others as much as others might.
From: Rob Warnock
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <8b-dnXgZDJOo663bnZ2dnUVZ_oWdnZ2d@speakeasy.net>
Kent M Pitman  <······@nhplace.com> wrote:
+---------------
| Ken Tilton <···@theoryyalgebra.com> writes:
| > Kent M Pitman wrote:
| > > Having done this, you can then do
| > >  (mapcar #'load '("pkgdcl.lisp" "my-defs.lisp" "my-callers.lisp"))
| > > but you can also break things up differently.
| > 
| > Add a remove-if there is a fasl with a more recent date and you have
| > ASDF beat.
| 
| Indeed, instead of load, a better function should be used that does all
| of that, yes.  I have my own source control system, and indeed it does 
| that extra hair.
+---------------

CMUCL's LOAD has a handy :IF-SOURCE-NEWER extension keyword:

   :IF-SOURCE-NEWER <keyword>
     If the file type is not specified, and both source and object files
     exist, then this argument controls which is loaded:
      :LOAD-OBJECT - load object file (default),
      :LOAD-SOURCE - load the source file,
      :COMPILE - compile the source and then load the object file, or
      :QUERY - ask the user which to load.

I have a little LOAD* function that remembers args you've given
it in the past, and given no args runs through the list checking
the source FILE-WRITE-DATE against the last time LOAD* was run,
and if the source is newer that the timestamp it does
(LOAD source :IF-SOURCE-NEWER :COMPILE). So if at some point
you say:

    (load* "pkgdcl.lisp" "my-defs.lisp" "my-callers.lisp")

then after that if you edit one or more of them and say just
(LOAD*), "the right thing" happens.

Yes, I use ASDF for bigger projects, but LOAD* gets me a long way
during development...


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Ken Tilton
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <KPgYh.962$qw6.504@newsfe12.lga>
Kent M Pitman wrote:
> Ken Tilton <···@theoryyalgebra.com> writes:
> 
> 
>>Kent M Pitman wrote:
>>
>>>Ken Tilton <···@theoryyalgebra.com> writes:
>>>
>>>I recommend breaking the [package declaration] off into a separate
>>>file.  Anyone who uses this package might want to be able to load
>>>the package definition, even people not planning to call the
>>>functions.
>>
>>Kind of an edge concern, don't you think? Should we scare noobs with
>>those? And I do not program that way.. maybe if one of the six people
>>using Cells asked for that, otherwise....
> 
> 
> Novices needn't understand the rationale, only the instruction to do the
> dogmatic action.

Do you use dog biscuits when training noobs? Or is a gentle slap on the 
snout enough to bring them into line?

>  The rationale is offered not to convince them, nor to
> make a case this will happen to them, but to give them the info they need
> later to accommodate situations they might not have expected and/or to 
> give up your rule when they've outgrown it.

Oh, OK, you know nothing about teaching. Dude, we want to make this as 
easy as possible, not hang all this extra obscure edge baggage around 
their necks. My 2, anyway.

> 
> My experience and the pitfalls I've seen may also be harsher than
> yours because on Lisp Machines, files wanted to cache information on
> the plist of the symbols, saying where the symbol is defined.

Jeez, Kent, give me some credit. You think I could not smell those 
Hollerith decks in your response? Ironiclly, your reference to the guy 
slobbering over CL back in the 1800s included him bemoaning CL was so 
bloated because it was trying to placate dinosaurs still using property 
lists as a database. Of course he know was wrong, property lists are 
brilliant, but still... was I making a point?


>>>Having done this, you can then do
>>> (mapcar #'load '("pkgdcl.lisp" "my-defs.lisp" "my-callers.lisp"))
>>>but you can also break things up differently.
>>
>>Add a remove-if there is a fasl with a more recent date and you have
>>ASDF beat.
> 
> 
> Indeed, instead of load, a better function should be used that does all
> of that, yes.  I have my own source control system, and indeed it does 
> that extra hair.

I need to know just one thing. Does your build utility try to compile 
evevrything before loading anything?

> Thanks for the reviews.  Since I live in my own little self-constructed
> universe of tools, I don't get a lot of cause to go playing with the 
> others as much as others might.

Word.

ken

-- 
http://www.theoryyalgebra.com/

"Algebra is the metaphysics of arithmetic." - John Ray

"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts

"Stand firm in your refusal to remain conscious during algebra."
    - Fran Lebowitz

"I'm an algebra liar. I figure two good lies make a positive."
    - Tim Allen
From: Edi Weitz
Subject: Re: First multi-file/package prog with lispworks personal edition on windows
Date: 
Message-ID: <uabwvwrgp.fsf@agharta.de>
On 25 Apr 2007 19:05:24 -0700, !!VV <········@gmail.com> wrote:

> I'm looking for instant nirvana for this:
>  --> Make a package, having a func say hw ==> (print "hello world")
>  --> use this in another 'main' file.
>  --> lispworks steps ( adding package directory etc ) for this.

I said this many times before, but I think it's worth repeating: Most
newbies (including you, I'm sure) say "package" when they mean
something else.  We usually say "system" or something like that for a
set of files that belong together and comprise a program or library.
A "package" is a defined term for a first-class object in the
language:

  http://www.lispworks.com/documentation/HyperSpec/Body/11_.htm

Maybe you should read a good introductory book:

  http://www.gigamonkeys.com/book/

> I'm wading through documentation, however a kickstart will be
> appreciated (-:

Have you looked at this?

  http://weitz.de/starter-pack/
  http://weitz.de/starter-pack/#own

HTH,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")