Dear All,
In order to implement a software I created a control file syntax which is a
list with keyword value pair, eg
((core-name c7552)
(num-inputs 25)
(num-outputs 10)
....)
Then I read it into a list (setq rx (read file-handle)).
I can access the value of any pair using (second (assoc 'core rx)).
I have a corresponding structure for Core-Info and I copy the value there.
(setf (core-info-name cs) (second (assoc 'core rx))).
All this is working fine (but if still some one can suggest better ways of
implementing control files for EDA tools in particular, I would be
thankful).
Then I created a Package :core-test and everything stopped working.
(setq rx (read file-handle)) still works but (assoc ..) does not work.
Is there an issue with using (defstruct..) with Packages (even though the
whole code is in a single file (in-package :core-test).
In order to make the structure visible outside what should I export ?
TIA
Sandeep
PS: The software is an EDA (tool almost) for scheduling algorithm for
embedded core test for SOC VLSI designs.
"Sandeep Koranne" <···············@nospam.philips.com> writes:
> Dear All,
> In order to implement a software I created a control file syntax which is a
> list with keyword value pair, eg
> ((core-name c7552)
> (num-inputs 25)
> (num-outputs 10)
> ....)
>
> Then I read it into a list (setq rx (read file-handle)).
>
> I can access the value of any pair using (second (assoc 'core rx)).
> I have a corresponding structure for Core-Info and I copy the value there.
> (setf (core-info-name cs) (second (assoc 'core rx))).
>
> All this is working fine (but if still some one can suggest better ways of
> implementing control files for EDA tools in particular, I would be
> thankful).
>
> Then I created a Package :core-test and everything stopped working.
> (setq rx (read file-handle)) still works but (assoc ..) does not work.
> Is there an issue with using (defstruct..) with Packages (even though the
> whole code is in a single file (in-package :core-test).
The "names" in the alist are symbols in the package that is
active at the time when you read in the file. If you do the (read... )
and the (assoc ...) operations inside the same package, everything
should work.
The *simplest* solution is probably to use the keyword package
for holding the names. Your example would then look something like
((:core-name c7552)
(:num-inputs 25)
(:num-outputs 10)
...)
(setf (core-info-name cs) (second (assoc :core rx)))
An alternative would be to have a separate package for the
"names", and export the names from this package. Note that this
package must be active at read time; alternatively, you cold use
explicit package markers in the input file.
> In order to make the structure visible outside what should I export ?
> TIA
>
> Sandeep
> PS: The software is an EDA (tool almost) for scheduling algorithm for
> embedded core test for SOC VLSI designs.
--
Raymond Wiker
·············@fast.no
From: Marco Antoniotti
Subject: Re: Q Re Exporting of Structures and some (un)related problems
Date:
Message-ID: <y6czo97ibfo.fsf@octagon.mrl.nyu.edu>
Raymond Wiker <·············@fast.no> writes:
> "Sandeep Koranne" <···············@nospam.philips.com> writes:
>
> > Dear All,
> > In order to implement a software I created a control file syntax which is a
> > list with keyword value pair, eg
> > ((core-name c7552)
> > (num-inputs 25)
> > (num-outputs 10)
> > ....)
> >
> > Then I read it into a list (setq rx (read file-handle)).
> >
> > I can access the value of any pair using (second (assoc 'core rx)).
> > I have a corresponding structure for Core-Info and I copy the value there.
> > (setf (core-info-name cs) (second (assoc 'core rx))).
> >
> > All this is working fine (but if still some one can suggest better ways of
> > implementing control files for EDA tools in particular, I would be
> > thankful).
> >
> > Then I created a Package :core-test and everything stopped working.
> > (setq rx (read file-handle)) still works but (assoc ..) does not work.
> > Is there an issue with using (defstruct..) with Packages (even though the
> > whole code is in a single file (in-package :core-test).
>
> The "names" in the alist are symbols in the package that is
> active at the time when you read in the file. If you do the (read... )
> and the (assoc ...) operations inside the same package, everything
> should work.
>
> The *simplest* solution is probably to use the keyword package
> for holding the names. Your example would then look something like
>
> ((:core-name c7552)
> (:num-inputs 25)
> (:num-outputs 10)
> ...)
>
> (setf (core-info-name cs) (second (assoc :core rx)))
>
> An alternative would be to have a separate package for the
> "names", and export the names from this package. Note that this
> package must be active at read time; alternatively, you cold use
> explicit package markers in the input file.
>
An even better solution would be to define a macro (maybe expanding
into a DEFCLASS) that represents all the items in the control file.
Of course this macro can be defined into a specialized package.
The "control file" would look like
(def-control "WHATEVER"
:core-name "c7552"
:num-inputs 25
:num-outputs 10
...)
Somewhere in the application you would have something like:
(defclass control-file ()
((core-name :accessor core-name :initarg :core-name)
(num-inputs :accessor num-inputs
:initarg :num-inputs
:type fixnum)
(num-outputs :accessor num-outputs
:initarg :num-outputs
:type fixnum)
...))
(defmacro def-control (name args &rest slots)
`(defclass ,name ,args ,@slots)) ; Or something more complex.
You will still able to READ your files (modulo the PACKAGE trickery)
and at the same time you will already have doen a lot of your
"semantics" parsing.
Bottom line. CL is an extensible language. Use it to define new
sublanguages.
Cheers
PS. I have seen some of the intermediate files of an EDA tools. It
was obvious that had the people known Lisp, the project would have
gotten done much earlier and with far less grievances.
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Ole Rohne
Subject: Re: Q Re Exporting of Structures and some (un)related problems
Date:
Message-ID: <ebwg0b0p8b4.fsf@lxplus042.cern.ch>
"Sandeep Koranne" <···············@nospam.philips.com> writes:
> Then I created a Package :core-test and everything stopped working.
> (setq rx (read file-handle)) still works but (assoc ..) does not work.
> Is there an issue with using (defstruct..) with Packages (even though the
> whole code is in a single file (in-package :core-test).
The reader (READ ...) interns symbols in the current package. My
impression is that it is good practice *not* to litter the CL-USER
package (or wherever the user runs your program) with this type of
random symbols. I think your're supposed to do something like:
(with-standard-usenet-disclaimers ; It worked for me, YMMV
(with-standard-io-syntax ; Isolate from dynamic bindings above
(let* ((*package (make-package "SCRATCH" :use nil))
(*read-eval* nil) ; Paranoid about what's in the file?
(rx (with-open-file (s "filename") (read s))))
;; Assuming (defvar *cs* ...) somewhere else
(setf (core-info-name *cs*) (second (assoc 'scratch::core rx))
(core-info-blah *cs*) (second (assoc 'scratch::blah rx))
(core-info-whatever *cs* (second (assoc 'scratch::whatever rx)))))
(delete-package "SCRATCH")))
I'm assuming you don't use "SCRATCH" to name a non-transient package
in your program. Actually, I'm wondering if there is a reserved
package name (possibly by convention) for this use?
Regards, Ole
From: Ole Rohne
Subject: Re: Q Re Exporting of Structures and some (un)related problems
Date:
Message-ID: <ebwae18p72n.fsf@lxplus042.cern.ch>
"Sandeep Koranne" <···············@nospam.philips.com> writes:
> ((core-name c7552)
Ole Rohne <·········@cern.ch> writes:
> (setf (core-info-name *cs*) (second (assoc 'scratch::core rx))
This won't even compile because the package "SCRATCH" is not supposed
to exist when the code is read. It looks like you'd have to use
(assoc (intern "CORE-NAME" *package*) rx)
and then even more package hacking for C7552 to end up in the package
you want. You could use strings to name your cores to avoid the last
step.
Regards, Ole
(on thin ice, waiting for authorities to speak:-0