DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

mbratch
Hello

I've been using GNU Smalltalk 3.2.5 with DBI without any serious issues.
However, when I tried version 3.2.91-b98173d, I get an error attempting
to connect to a simple MySQL database:

|st> PackageLoader fileInPackage: 'DBI' Loading package ROE Loading
package DBI PackageLoader st> PackageLoader fileInPackage: 'DBD-MySQL'
Loading package ObjectDumper Loading package Sockets Loading package DBI
Loading package Digest Loading package DBD-MySQL PackageLoader st> db :=
DBI.Connection connect: 'dbi:MySQL:dbname=test_database' user: 'name'
password: 'mypassword' Object: nil error: did not understand #atEnd |

I have 3.2.5 and 3.2.91-b98173d in two different source directories.
When I want to use one of them, I use `make install` to install it. I'm
assuming that the `make install` will overwrite whatever it needs to in
library/binary folders to operate properly. Is this not a good assumption?

Thanks

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Holger Freyther

> On 29 Aug 2015, at 21:31, Mark Bratcher <[hidden email]> wrote:
>
> Hello

Hi!


> I've been using GNU Smalltalk 3.2.5 with DBI without any serious issues. However, when I tried version 3.2.91-b98173d, I get an error attempting to connect to a simple MySQL database:
>
> |st> PackageLoader fileInPackage: 'DBI' Loading package ROE Loading package DBI PackageLoader st> PackageLoader fileInPackage: 'DBD-MySQL' Loading package ObjectDumper Loading package Sockets Loading package DBI Loading package Digest Loading package DBD-MySQL PackageLoader st> db := DBI.Connection connect: 'dbi:MySQL:dbname=test_database' user: 'name' password: 'mypassword' Object: nil error: did not understand #atEnd |

My first guess would be that the authentication has failed and that the
underlying stream is nil.

The MySQL test is ran on the travis-ci build and it passed the last time[1].
So in some configuration it works with master as well.




> I have 3.2.5 and 3.2.91-b98173d in two different source directories. When I want to use one of them, I use `make install` to install it. I'm assuming that the `make install` will overwrite whatever it needs to in library/binary folders to operate properly. Is this not a good assumption?

It is a good assumption. make install should install everything and the MySQL
package should not accidentally pull in old things.

kind regards
        holger


[1] https://travis-ci.org/gnu-smalltalk/smalltalk#L3793



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Holger Freyther

> On 29 Aug 2015, at 23:53, Mark Bratcher <[hidden email]> wrote:
>
>>
> The exact same connection works fine under Smalltalk 3.2.5. So it's not an authentication issue in my case. I tried it on a couple of different databases, each time working in 3.2.5, but the same error using 3.2.91-b98173d.


that is odd. The difference from 3.2.5 to master in dbd-mysql itself is that I removed
commitTransaction/rollbackTransaction because the super class already had these
selectors.

If it isn’t too much work for you could you do the following (once fro 3.2.5 and once
for master):

* Use wireshark/tcpdump to record a packet trace of the GST/MySQL communication
(maybe change the PW to something different..)
* Show the code that was used
* And the exception?


kind regards
        holger
_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

mbratch
Holger

I believe I found the problem.

The socket is connecting fine. But digging into the connection code, I
found that a `class new` operation now automatically calls the
`initialize` method in 3.2.91-b98173d, but it does not do so in 3.2.5.
This causes a problem in the MySQLPacket and MySQLInputPacket connection
code and results in `MySQLInputPacket >> initialize` being called too
early in `^(self new) stream: aStream ; initialize` inside of `
MySQLPacket class >> on: aStream`. It's called automatically on `self
new` before the stream is set.

Mark


On 8/30/2015 2:13 AM, Holger Freyther wrote:

>> On 29 Aug 2015, at 23:53, Mark Bratcher <[hidden email]> wrote:
>>
>> The exact same connection works fine under Smalltalk 3.2.5. So it's not an authentication issue in my case. I tried it on a couple of different databases, each time working in 3.2.5, but the same error using 3.2.91-b98173d.
>
> that is odd. The difference from 3.2.5 to master in dbd-mysql itself is that I removed
> commitTransaction/rollbackTransaction because the super class already had these
> selectors.
>
> If it isn’t too much work for you could you do the following (once fro 3.2.5 and once
> for master):
>
> * Use wireshark/tcpdump to record a packet trace of the GST/MySQL communication
> (maybe change the PW to something different..)
> * Show the code that was used
> * And the exception?
>
>
> kind regards
> holger


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Holger Freyther

> On 31 Aug 2015, at 04:51, Mark Bratcher <[hidden email]> wrote:
>
> Holger

Hi!


> I believe I found the problem.


oops!


> The socket is connecting fine. But digging into the connection code, I found that a `class new` operation now automatically calls the `initialize` method in 3.2.91-b98173d, but it does not do so in 3.2.5. This causes a problem in the MySQLPacket and MySQLInputPacket connection code and results in `MySQLInputPacket >> initialize` being called too early in `^(self new) stream: aStream ; initialize` inside of ` MySQLPacket class >> on: aStream`. It's called automatically on `self new` before the stream is set.

I tried to align this semantic to Pharo (as porting from/to Pharo gets easier). Thank
you for your analysis! The question is why does the CI pass? Did I by accident not
go through authentication?

I will try to reproduce and integrate a fix this week.

holger



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

mbratch
Hi Holger

Thanks again for being so responsive.

After doing some admittedly light research on the `new` method versus
`initialize`, it looks like Pharo (and probably, therefore, Squeak) is
the only variant of Smalltalk that automatically calls an instance
initializer (`initialize`) on `new`. If GNU Smalltalk is following this
to be easier to port from Pharo, that raises a philosophical question
for GNU Smalltalk: is intended for it to align as much as possible with
the Pharo implementation (and then perhaps, ultimately, become a "Pharo
variant"), or to attempt to remain more "pure" (whatever that might mean
:)) relative to Smalltalk-80? I noticed in various texts discussion
Smalltalk class instance creation, specifically show a pattern something
like:

     Foo class >> new [
         ^super new initialize
     ]

Mark

On 8/31/2015 2:09 AM, Holger Freyther wrote:

>> The socket is connecting fine. But digging into the connection code, I found that a `class new` operation now automatically calls the `initialize` method in 3.2.91-b98173d, but it does not do so in 3.2.5. This causes a problem in the MySQLPacket and MySQLInputPacket connection code and results in `MySQLInputPacket >> initialize` being called too early in `^(self new) stream: aStream ; initialize` inside of ` MySQLPacket class >> on: aStream`. It's called automatically on `self new` before the stream is set.
> I tried to align this semantic to Pharo (as porting from/to Pharo gets easier). Thank
> you for your analysis! The question is why does the CI pass? Did I by accident not
> go through authentication?
>
> I will try to reproduce and integrate a fix this week.
>
> holger
>
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Holger Freyther

> On 31 Aug 2015, at 12:28, Mark Bratcher <[hidden email]> wrote:
>
> Hi Holger

Hi,

> Thanks again for being so responsive.
>
> After doing some admittedly light research on the `new` method versus `initialize`, it looks like Pharo (and probably, therefore, Squeak) is the only variant of Smalltalk that automatically calls an instance initializer (`initialize`) on `new`. If GNU Smalltalk is following this to be easier to port from Pharo, that raises a philosophical question for GNU Smalltalk: is intended for it to align as much as possible with the Pharo implementation (and then perhaps, ultimately, become a "Pharo variant"), or to attempt to remain more "pure" (whatever that might mean :)) relative to Smalltalk-80? I noticed in various texts discussion Smalltalk class instance creation, specifically show a pattern something like:


it is a pragmatic decision. The GNU Smalltalk community is not very large and
there are not many projects that get created for GNU Smalltalk (e.g. Iliad was a
notable exception). With gst-convert we have a tool to convert from other dialects
but in recent times I think I/we only ported from Pharo.

I don’t think there is intention to be “Pharo compatible”. E.g. String/Symbol will
not be considered equal. There is no plans to introduce a ProtoObject and maybe
not even the “MetaLink”.. at least not to kernel/

At the same time I started to use the >>#new/#initialize pattern as well so it fellt
like a natural progress.

kind regards
        holger







_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

mbratch
Thank you, Holger.

I understand the pragmatics of the decision. One could argue that, in the
current bug case, the `(self new) stream: aStream ; initialize` statement
is a bit "off-pattern". :) I think it's a little unfortunate that Pharo
deviated from Smalltalk-80 in a small, but fundamental way. I think it
means that if I want to write more portable Smalltalk code, I might avoid
using "initialize" since its behavior will be different in Pharo (and now
GNU) versus other implementations. Such avoidance would be necessary in
cases where one wants instance initialization to be deferred after instance
creation.

Kind regards

Mark

On Mon, Aug 31, 2015 at 7:13 AM, Holger Freyther <[hidden email]> wrote:

>
> > On 31 Aug 2015, at 12:28, Mark Bratcher <[hidden email]> wrote:
> >
> > Hi Holger
>
> Hi,
>
> > Thanks again for being so responsive.
> >
> > After doing some admittedly light research on the `new` method versus
> `initialize`, it looks like Pharo (and probably, therefore, Squeak) is the
> only variant of Smalltalk that automatically calls an instance initializer
> (`initialize`) on `new`. If GNU Smalltalk is following this to be easier to
> port from Pharo, that raises a philosophical question for GNU Smalltalk: is
> intended for it to align as much as possible with the Pharo implementation
> (and then perhaps, ultimately, become a "Pharo variant"), or to attempt to
> remain more "pure" (whatever that might mean :)) relative to Smalltalk-80?
> I noticed in various texts discussion Smalltalk class instance creation,
> specifically show a pattern something like:
>
>
> it is a pragmatic decision. The GNU Smalltalk community is not very large
> and
> there are not many projects that get created for GNU Smalltalk (e.g. Iliad
> was a
> notable exception). With gst-convert we have a tool to convert from other
> dialects
> but in recent times I think I/we only ported from Pharo.
>
> I don’t think there is intention to be “Pharo compatible”. E.g.
> String/Symbol will
> not be considered equal. There is no plans to introduce a ProtoObject and
> maybe
> not even the “MetaLink”.. at least not to kernel/
>
> At the same time I started to use the >>#new/#initialize pattern as well
> so it fellt
> like a natural progress.
>
> kind regards
>         holger
>
>
>
>
>
>
>
_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Holger Freyther

> On 31 Aug 2015, at 14:08, Mark Bratcher <[hidden email]> wrote:
>
> Thank you, Holger.
>
> I understand the pragmatics of the decision. One could argue that, in the current bug case, the `(self new) stream: aStream ; initialize` statement is a bit "off-pattern". :) I think it's a little unfortunate that Pharo deviated from Smalltalk-80 in a small, but fundamental way. I think it means that if I want to write more portable Smalltalk code, I might avoid using "initialize" since its behavior will be different in Pharo (and now GNU) versus other implementations. Such avoidance would be necessary in cases where one wants instance initialization to be deferred after instance creation.

Yes, it is unfortunate. But if you look at the diff that introduced this behavior then
you see that it was used a lot already. In both Pharo and GST there is >>#basicNew
as well but I don’t know if this is in an ANSI protocol.

So e.g. this could fix the issue you have debugged:

diff --git a/packages/dbd-mysql/Connection.st b/packages/dbd-mysql/Connection.st
index b97dc89..ef5ac65 100644
--- a/packages/dbd-mysql/Connection.st
+++ b/packages/dbd-mysql/Connection.st
@@ -237,7 +237,7 @@ Object subclass: MySQLPacket [
 
     MySQLPacket class >> on: aStream [
        <category: 'instance creation'>
-       ^(self new)
+       ^(self basicNew)
            stream: aStream;
            initialize
     ]



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

mbratch
Holger

I think that using `basicNew` is reasonable pattern for a solution in this
case. Thank you!

Mark

On Mon, Aug 31, 2015 at 8:17 AM, Holger Freyther <[hidden email]> wrote:

>
> > On 31 Aug 2015, at 14:08, Mark Bratcher <[hidden email]> wrote:
> >
> > Thank you, Holger.
> >
> > I understand the pragmatics of the decision. One could argue that, in
> the current bug case, the `(self new) stream: aStream ; initialize`
> statement is a bit "off-pattern". :) I think it's a little unfortunate that
> Pharo deviated from Smalltalk-80 in a small, but fundamental way. I think
> it means that if I want to write more portable Smalltalk code, I might
> avoid using "initialize" since its behavior will be different in Pharo (and
> now GNU) versus other implementations. Such avoidance would be necessary in
> cases where one wants instance initialization to be deferred after instance
> creation.
>
> Yes, it is unfortunate. But if you look at the diff that introduced this
> behavior then
> you see that it was used a lot already. In both Pharo and GST there is
> >>#basicNew
> as well but I don’t know if this is in an ANSI protocol.
>
> So e.g. this could fix the issue you have debugged:
>
> diff --git a/packages/dbd-mysql/Connection.st
> b/packages/dbd-mysql/Connection.st
> index b97dc89..ef5ac65 100644
> --- a/packages/dbd-mysql/Connection.st
> +++ b/packages/dbd-mysql/Connection.st
> @@ -237,7 +237,7 @@ Object subclass: MySQLPacket [
>
>      MySQLPacket class >> on: aStream [
>         <category: 'instance creation'>
> -       ^(self new)
> +       ^(self basicNew)
>             stream: aStream;
>             initialize
>      ]
>
>
>
_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: DBI.Connection call yields "Object: nil error: did not understand #atEnd" in ST 3.2.91-b98173d

Holger Freyther

> On 31 Aug 2015, at 15:11, Mark Bratcher <[hidden email]> wrote:
>
> Holger
>
> I think that using `basicNew` is reasonable pattern for a solution in this case. Thank you!
>

did you try the patch with basicNew? Did it work? I try to squeeze out some time to understand
why the failure didn’t occur on the travis build.

holger


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