STInST Parser and parsing Glut (and other code)

Hi,

I am flying right now and looked into how many of our packages can
be parsed using the Parser package. I skipped the Glib package and
now I am looking into Glut and it appears that this is a problem
my colleague had yesterday.

The following code works with the libgst/ parser but causes an
exception with STInST.

Object subclass: Test [
        | var |
]

Test extend [
        | newVar |
]


holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, Sep 20, 2013 at 04:31:40PM +0200, Holger Hans Peter Freyther wrote:

Hi,


> I am flying right now and looked into how many of our packages can
> be parsed using the Parser package. I skipped the Glib package and
> now I am looking into Glut and it appears that this is a problem
> my colleague had yesterday.

I found some more parsing issues..


GNUPlot:
  GNUPlot.GNUPlot exsists breaking the look-up (just like Cairo did
  before renaming it). Now there is Already GPPlot as a class. The
  question is if I should use GNUPlot.Plot?

  #(##(1/2) 2) can not be parsed with STInST (GSTFileInParser)

NetClients:
  Some issue with resolving the namespace..

'Namespace error: Invalid argument nil: must be a Smalltalk.Dictionary or a Smalltalk.Class'
SystemExceptions.WrongClass(Smalltalk.Exception)>>signal (ExcHandling.st:254)
SystemExceptions.WrongClass class>>signalOn:mustBe: (SysExcept.st:783)
Smalltalk.Namespace class>>current: (Namespace.st:94)
Smalltalk.UndefinedObject>>executeStatements (source not available:1)

Sandstone:
  Object subclasS: SDActiveRecord [
   SDActiveRecord class [
     Store := nil.
   ]
  ]

 This is creating a class variable with the libgst Parser.. it breaks
 STInST.

Glib:
 Some kind of namespace issue..


holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 22/09/2013 06:32, Holger Hans Peter Freyther ha scritto:
GPPlot is something that you add to a GNUPlot instance.  I guess we have
to fix the problem, we cannot do the same as Cairo.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, Sep 22, 2013 at 12:45:09PM +0200, Paolo Bonzini wrote:

> GPPlot is something that you add to a GNUPlot instance.  I guess we have
> to fix the problem, we cannot do the same as Cairo.

How do you define the semantic?

Namespace current: GNUPlot [
        Object subclass: GNUPlot [
                Foo := nil.

                foo [
                        ^GNUPlot.Foo
                ]

                bla [
                        ^Foo
                ]
        ]

        Object subclass: SomethingPlog [
                foo [
                        ^GNUPlot.Foo
                ]
        ]

        Object subclass: Foo [
               
        ]
]


 >>#bla and >>#foo the bytecode appears to be:

    [3] source code line number 2
        push Global Variable #Foo->nil
    [5] return stack top

Which means foo is resolved at runtime that one can never access
a class variable?


holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 22/09/2013 13:13, Holger Hans Peter Freyther wrote:
Hi,

if we accept that the class name *cannot* be the same as the namespace
name hence the code becomes:

Namespace current: GNUPlot [
     Gplot >> foo [
     ^GNUPlot.Foo
     ]
]


The compiler will create a DeferedVariableBinding and when Foo class is
created it replaces the DeferedVariableBinding with a VariableBinding.

Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, Sep 22, 2013 at 06:32:47AM +0200, Holger Hans Peter Freyther wrote:

> GNUPlot:
>   GNUPlot.GNUPlot exsists breaking the look-up (just like Cairo did
>   before renaming it). Now there is Already GPPlot as a class. The
>   question is if I should use GNUPlot.Plot?


I used the VisualGST Debugger (and found some more issues) but looking
at the stack trace I saw that the STEvaluationDriver is doing:

        method := evalFor class compilerClass
                    compile: node
                    asMethodOf: evalFor class
                    classified: nil
                    parser: self
                    environment: Namespace current.
        [lastResult := evalFor perform: method] valueWithUnwind.

in the case of GNUPlot "evalFor class" is UndefinedObject,
environment should be self currentNamespace (and not Namespace)
but the compiled method is still doing:

        "Smalltalk.GNUPlot instanceVariables: 'abc def'"

while it should be:

        "GNUPlot.GNUPlot instanceVariables: 'abc def'".

So it appears that the STCompiler is somehow "ignoring" the namespace
that I pass in? Paolo do you have an idea of why that is the case?


holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, Dec 17, 2013 at 10:01:52AM +0100, Holger Hans Peter Freyther wrote:

> "GNUPlot.GNUPlot instanceVariables: 'abc def'".

Interestingly.. when using

        Namespace current: Bla [
                Object subclass: Bla [
                        | inst |
                ]
        ]

is working correctly. While loading GNUPlot triggers the issue. The
namespace is probably set-up by PackageLoader.


Namespace current: (Smalltalk addSubspace: 'Doo').

Object subclass: Doo [
                | foo |
]



> So it appears that the STCompiler is somehow "ignoring" the namespace
> that I pass in? Paolo do you have an idea of why that is the case?

it is probably an issue with the symbol table.

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, Dec 19, 2013 at 02:01:38PM +0100, Holger Hans Peter Freyther wrote:

> > So it appears that the STCompiler is somehow "ignoring" the namespace
> > that I pass in? Paolo do you have an idea of why that is the case?
>
> it is probably an issue with the symbol table.

Close. It is the DefaultPoolResolution>>#lookupBindingOf:. Even if the
current namespace is "Doo". "Doo" will be searched _after_ the Smalltalk
namespace.

So in STCompiler>>#compile:..

 aNamespace isNil ifFalse: [compiler addPool: aNamespace].


should probably become something like addPoolFirst: and STSymbolTable>>#
addPoolFirst should be added too.

comments?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk