CStruct and another set of weird issues

Hi,

I have another set of issues and they are a bit too much to know where I
should start.

I have this C Struct:

struct vty_app_info {

        const char *name;
        const char *version;
        const char *copyright;
        void *tall_ctx;
        enum node_type (*go_parent_cb)(struct vty *vty);
        int (*is_config_node)(struct vty *vty, int node);
};

For the last three members I actually can cope with only having dummies to
make the CStruct sizeof the right size... So I came up with this, at least it
has the right size.

CStruct subclass: vty_app_info [
    <category: 'libosmovty'>
    <comment: 'I represent the vty_app_info... some structs are wrong'>
    <declaration: #(
        (#name #string)
        (#version #string)
        (#copyright #string)
        (#tall_ctx (#ptr #int))
        (#go_parent_cb (#ptr #int))
        (#is_config_node (#ptr #int))) >
]

Using the gst shell, I can file in the above file, if I use gst-remote --eval
"FileStream fileIn: 'OsmoVTY.st'" I get a weird parse error with the STinST
parser, if I fileIn in VisualGST my vty_app_info lacks the gcNew call. This is
all very mysterious.


Any pointer on how to debug that would be welcome.

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

On 09/11/2010 03:18 PM, Holger Hans Peter Freyther wrote:

>
> Any pointer on how to debug that would be welcome.
>

Apparently I need to write Smalltalk.vty_app_info in VisualGST and typing
CStruct subclass: Foo [ <declaration: #( #(#name #string) )> ]. fails to
parse, maybe for the same reason that gst-remote does not work?

fun

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

> Apparently I need to write Smalltalk.vty_app_info in VisualGST

What do you mean?

> and typing
> CStruct subclass: Foo [ <declaration: #( #(#name #string) )> ]. fails to
> parse, maybe for the same reason that gst-remote does not work?

Yes, VisualGST also uses STInST to parse.  Likely a bug in the GSTParser class.

Paolo

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

On 09/11/2010 08:34 PM, Paolo Bonzini wrote:

>> CStruct subclass: Foo [ <declaration: #( #(#name #string) )> ]. fails to
>> parse, maybe for the same reason that gst-remote does not work?
>
> Yes, VisualGST also uses STInST to parse.  Likely a bug in the GSTParser class.

Typing the above class in anything that has an 'Accept' will open the
debugger. It appears that

CStruct class>>#declaration: is not called with a proper array but the RB
representation of #( #(#name #string) ) (( RBLiteralToken((
RBLiteralToken(#name)  RBLiteralToken(#string) )) )).

So it appears that something is missing to go from there to array and pass
that into the declaration.  Could you hint me of where this should/could
happen? E.g. in GSTFileInParser>>parseClassTag?

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

On 09/13/2010 03:37 AM, Holger Hans Peter Freyther wrote:

> So it appears that something is missing to go from there to array and pass
> that into the declaration.  Could you hint me of where this should/could
> happen? E.g. in GSTFileInParser>>parseClassTag?

diff --git a/packages/stinst/parser/GSTParser.st
b/packages/stinst/parser/GSTParser.st
index a96e936..2b194a2 100644
--- a/packages/stinst/parser/GSTParser.st
+++ b/packages/stinst/parser/GSTParser.st
@@ -253,7 +253,7 @@ STInST.STFileInParser subclass: GSTFileInParser [
                      self evaluateStatement: stmt]
             ifFalse: [self evaluateMessageOn: taggee
                            selector: selector
-                           argument: argument token value]
+                           argument: argument value]
     ]

     parseClassVariable [


this is fixing my test case, now the question is what am I going to break?

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

On 09/12/2010 09:55 PM, Holger Hans Peter Freyther wrote:
I think nothing.

Paolo

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

On 09/13/2010 03:37 PM, Paolo Bonzini wrote:

>> this is fixing my test case, now the question is what am I going to break?
>
> I think nothing.

Okay, so here is my proposal...



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

On 09/13/2010 10:40 AM, Holger Hans Peter Freyther wrote:
> On 09/13/2010 03:37 PM, Paolo Bonzini wrote:
>
>>> this is fixing my test case, now the question is what am I going to break?
>>
>> I think nothing.
>
> Okay, so here is my proposal...

Applied, thanks.

Paolo

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

On 09/13/2010 06:10 PM, Paolo Bonzini wrote:

> Applied, thanks.

There is still one more issue with importing Cairo and probably GTK with the
STinST parser/compiler. I am struggling with GC and C Callouts right now and
then will get back to this.


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