[Glass] PDFtalk for GemStone questions

Fri Oct 27 05:18:45 PDT 2017

I copied the PDFtalk symbol dictionary from PDFtalkLibrary into my user symbol list. That solved my namespace reference problems. Christian may have a better answer.
Bob NemecHTS 

    On Thursday, October 26, 2017 8:48 PM, Dale Henrichs via Glass <glass at lists.gemtalksystems.com> wrote:

 On 10/26/17 5:01 PM, Jupiter Jones via Glass wrote:

 Hiya, 
  I’m checking out Christians’ PDFtalk library in GemStone and had a couple of queries. 
  After loading the PDFtalk.gs and PDFtalkTesting.gs I wanted to check out the demos and have a play with making my own PDF. Well, I haven't had a chance to load PDFtalk, myself so I'm flying a little blind...I took a quick look at the filein script 

  In tODE:  browse symbolDict PDFtalk  Definitions -------------------- AttributeType{55005953}  ArrayType{54966017}  DictionaryType{55295745}   NameTreeType{54969089}  DirectType{55471873}  IndirectType{55468801}  ObjectType{54939393}  UndefinedType{54924545} … etc  
  browse symbolDict PDFtalkLibrary  Definitions -------------------- ByteReadStream{55300097} ByteWriteStream{55566081} ColorValue{55527169} CoverageValue{37341953} Emitter{55524097}  SourceEmitter{55521025}   Blockemitter{55496449}   Lineemitter{55490305}  TextEmitter{55511809}   TextBlockemitter{55508737}   TextLineemitter{55484161} OrderedDictionary{55493377} PDF{55558913} Timestamp{55530241} … etc  
  I haven’t seen the oops in {} in tODE before. Do they indicate something? 
 The oops in '{}' after a class name in the browse means that you are looking at a TDBehaviorReferenceDefinition instead of a TDClassDefinition ... A TDBehaviorReferenceDefinition gets created (TDClassDefinition class>>fromClassWithHistory:) when a class instance is encountered that is not in the class history of a "known class" (i.e., `Smalltalk at: className`) OR you are looking at a  class instance that is the symbol list of another user ... From what I can tell in reading the code in the beginning of the filein, neither of these cases appear to apply ...

 How did you load the .gs files?

  The first demo (for example) in the PDF class is a HelloWorld:  demo01_HelloWorld   "PDF demo01_HelloWorld" 
    | page |   page := PDF Page     newInBounds: (0 @ 0 corner: 70 @ 20)     colorspace: (PDF classAt: #'DeviceCMYK') new     render: [ :renderer |        renderer fillColor: CmykColor black.       renderer         textObjectDo: [            renderer setFont: #'Helvetica' size: 10.           renderer add: (NextLineRelative operands: #(10 5)).           renderer showString: 'Hello World' ] ].   page saveAndShowAs: ‘demo01_HelloWorld.pdf'  
  I selected the comment text in tOODE and inspected it (CMD-I) and got the error: CompileError occurred (error 1001), undefined symbol  PDF 
  If PDFtalkLibrary is in my symbol list, shouldn’t the compiler ‘see’ the PDF class? 
 From reading the code, I would agree with you ... so there is something going on that does not meet the eye .. Have you inspected PDFtalkLibrary to verify that an Association with the PDF class is present ...

 Again I am curious how you have loaded the .gs  files ... have you logged into and out of your tODE session after loading the .gs files (presumably in a topaz session)? The symbol list used for lookup in a session is a copy of the persistent symbol list that was present at login ... so if you do operations that affect the persistent symbol list in another session you probably should logout and back in 

  I tried the same thing in Topaz and it worked as expected - saved the PDF in my home directory, 
 Yeah my guess is that the session symbol list is the culprit ...

  I’ve updated to the latest tODE and am testing in GS3.3.6. 
  In the demo method above, CmykColor (defined in PDFtalkLibrary in my symbol'ist) and NextLineRelative (defined in PDFtalk not in my symbol list, but defined in PDFtalkLibrary) also appear undefined in tODE. In Topaz, CmykColor is visible, but not NextLineRelative… 
   topaz 1> printit NextLineRelative % GemStone Smalltalk Compiler Errors:    NextLineRelative  * ^1                                                                 ******* 
  1: [1031] undefined symbol topaz 1> printit CmykColor % a metaCmykColor   superClass          a metaValue   format              0   instVarsInfo        1125899906846726   instVarNames        a Array   constraints         a Array   classVars           nil   methDicts           a GsMethodDictionary   poolDictionaries nil   categorys           a GsMethodDictionary   primaryCopy         nil   name                CmykColor   classHistory        a ClassHistory   transientMethDicts a Array   destClass           nil   timeStamp           a DateTime   userId              DataCurator   extraDict           a SymbolDictionary   classCategory       PDFtalk Colour   subclasses          nil topaz 1>   
  That makes sense to me as PDFtalk is not in my symbol list. 
  So… :) 
  How do I go about running these methods in tODE? 
 Like I said, I think a login/logout is needed in tODE ... tODE doesn't do class lookup any different than topaz ... 

 Now I think that Christian was trying to duplicate the kind name space semantics available in VW so he's wired things to hide certain classes using PDFtalk:
 DoIt
TextPositioningOperation
	subclass: 'NextLineRelative'
	instVarNames: #()
	classVars: #()
	classInstVars: #()
	poolDictionaries: #()
	inDictionary: PDFtalk
%

I haven't looked closely and won't have time to dig into this until the weekend, but I did notice that Christian is using a SymbolDictionary named FileInSymbolDictionary that houses PDFTalk... and 
FileInSymbolDictionary is deleted after the filein completes ... so it seems that this is how Christian has been able to compile in references to "hidden" classes ... and that explains how the {} oops are showing up for the classes you are looking at ... any class that is not found in the current symbol list lookup will have a {} tacked on ...

Do you know where the global PDF is defined in the filein? It is about impossible to search for the global PDF in the filein (there are a 1000+ matches)

 How is Topaz running the #demo01_HelloWorld method, but the compiler not see NextLineRelative?  
  As Christian describes in : https://wiki.pdftalk.de/doku.php?id=pdftalk4gemstone shouldn't the code be PDFtalk at: #NextLineRelative. The demo method executes fine without that in Topaz, which breaks my understanding of GS symbol lists :) 
   topaz 1> printit PDFtalk at: #NextLineRelative % a metaNextLineRelative   superClass          a metaTextPositioningOperation   format              0   instVarsInfo        1125899906846721   instVarNames        a Array   constraints         a Array   classVars           nil   methDicts           a GsMethodDictionary   poolDictionaries nil   categorys           a GsMethodDictionary   primaryCopy         nil   name                NextLineRelative   classHistory        a ClassHistory   transientMethDicts a Array   destClass           nil   timeStamp           a DateTime   userId              DataCurator   extraDict           a SymbolDictionary   classCategory       PDFtalk Graphics Operations   subclasses          nil  
  If there’s something really obvious I’m missing, point me at the docs and I’ll being myself up to date. I’ve read the GS docs about symbol lists again, but am still not sure what’s going on here. 
 The key clue will be to find out where the PDF global is defined -- and I am still curious how you filed in the .gs files ...

  Cheers, 
  J 

 _______________________________________________
Glass mailing list
Glass at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/glass

 _______________________________________________
Glass mailing list
Glass at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20171027/48922c82/attachment-0001.html>