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. 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 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? I tried the same thing in Topaz and it worked as expected - saved the PDF in my home directory, 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? 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. Cheers, J _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 10/26/17 5:01 PM, Jupiter Jones via
Glass wrote:
Hiya,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 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? 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 Yeah my guess is that the session symbol list is the culprit ... 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) 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 ...
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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 Nemec HTS On Thursday, October 26, 2017 8:48 PM, Dale Henrichs via Glass <[hidden email]> 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 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? 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 Yeah my guess is that the session symbol list is the culprit ... 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) 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 ...
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |