Re: package frenzy



Hi Pascal,

Don't I know you from somewhere? ;)

Maybe, I was a bit unclear with my problem statement. The symbol is not part of the API and should remain unvisible for the users of :exporting-package. So I guess what I want to do is to make sure that the result of the call to the read-line fn returns a symbol inside the :exported-package, but I don't know how to do so. Both ep-internal-fn and ep-external-fn are defined in the package :exporting-package (using in-package).

Ok, I tried to abstract my problem a bit, trying to make the problem as clear as possible, but my attempt ended in a disaster :).


The :exporting-package really is a client. This client uses simple crlf-ended lines over a tcp-connection. Now for extracting the commands they receive, the first word of this line always resembles the command sended and is implemented in ep-internal-fn (the real name is
reply->command. It is actually implemented as a (read-from-string reply nil nil).


The ep-external-fn is of a higher-level like 'start-client' and checks the incoming commands from the server are eq to the expected command. So the comparisons are used inside the ep-external-fn and should not be visible to the user of the :exporting-package.

Maybe you want (intern string :exporting-package) instead of read-line?

This might indeed be the function I'm looking for. It seems more elegant than setting *package* by hand. Oops, just read your reply :p, so I might look very stupid now :). But I indeed want to make the read-from-string result internal. Problem is, that has got no name, as it is just past as the return value of a function straight in the eq-test.


However, doing so requires the programmer to be realy careful when employing packages. I'd like to think that calling internal functions should automagically change the *package* to the package it was internal in, but I guess there are good reasons, which I don't yet fully (and might never :)) understand, for not doing so.

But indeed this sounds like a strange attempt. It sounds as if you wanted to use packages just to get more efficient string comparisons. Wouldn't a hashtable be good enough for such a purpose?

This package is actually used to get to a higher level of commands and thus does more than a simple string comparisons. Hashtables are a good idea, but the protocol used is very straight forward and this might result in overkill, at least in the client.


Thanks for your advice and the time for writing it down!

Joris

.



Relevant Pages

  • Re: Finding installed package files
    ... >, and who is going to supply this documentation. ... > is a package with the common man pages for the thousand odd common commands ... tell me, as an installation option for some large packages, what was ... >>a set of commands and 'man' pages, could produce such a directory to make it ...
    (alt.os.linux.redhat)
  • Re: Finding installed package files
    ... is a package with the common man pages for the thousand odd common commands ... Seeing as how 18 percent of the package is documentation - have you looked ... >a set of commands and 'man' pages, could produce such a directory to make it ... There are 16 books in front of me between the monitors, ...
    (alt.os.linux.redhat)
  • Re: New list commands ... What do you think ?
    ... That's the risk of every developer writing basic commands. ... allow some discussion about some of them, that are really good for core ... runtime consuming and could be done more efficiencly in C using the tcl ... Critcl builds a package which is loaded. ...
    (comp.lang.tcl)
  • Re: Plotchart ideas (was: Can BLT be replaced by Tcl packages ?)
    ... I finally used the graphic commands of Plotchart instead of the BLT ... package require Tcl ... I can easily make a loop to compute the maximum y label string length. ...
    (comp.lang.tcl)
  • Re: Writing extensions in C: questions:
    ... The correct way to set the interpreter ... >provide], which says it is invoked when the package is finally loaded, ... It seems to me this would result in additional commands being ... >created commands if anything subsequently fails during init? ...
    (comp.lang.tcl)