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 |
> 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 |
> 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 |
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 |
> 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 |
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 |
> 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 |
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 |
> 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 |
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 |
> 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 |
Free forum by Nabble | Edit this page |