June 2010 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Glorp & PostgresV2

by Mariano Martinez Peck

On Fri, Jun 11, 2010 at 10:49 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Mariano, > > I had to change PGConnection class>>#timestampWithTimezoneConverter > otherwise it wouldn't want to parse my timestamp with time zone colums that > look like '2010-06-16 00:01:00+02' (no millis to skip, no minutes in the > offset). Now, my fix is a bit dirty, because it assumes that what I see on > my system is the rule while it probably isn't. > > timestampWithTimezoneConverter > > ^[ :s | > | direction offset | > direction := (s at: 20) = $- ifTrue: [ -1 ] ifFalse: [ 1 ]. > offset := Duration > hours: (s copyFrom: 21 to: 22) asInteger * > direction. > DateAndTime > year: (s copyFrom: 1 to: 4) asInteger > month: (s copyFrom: 6 to: 7) asInteger > day: (s copyFrom: 9 to: 10) asInteger > hour: (s copyFrom: 12 to: 13) asInteger > minute: (s copyFrom: 15 to: 16) asInteger > second: (s copyFrom: 18 to: 19) asInteger > offset: offset ] > > I can definitively write a better version that handles different kinds of > formats in a flexible way. I also think the #copyFrom:to:'s are waistful and > could at least be replaced with ReadStream>>#on:from:to:'s. This goes for > some other converters as well. This code is execute for each column so seems > resource critical. > > The problem with this is what you said: maybe it is not a normal problem, but just for *you*. I don't know. Maybe you should ask in Glorp mailing list ? > This change did not come up as a failed unit test, so maybe I should also > try to add one ? > > and yes, if it is a generic problem, it would be great to generate a test and commit both ;) > On my Pharo 1.0 image, all PGConnection tests pass. > > Of the 844 GlorpTest tests, 2 fail: > GlorpRowMapForMementosCollectionTest>>#testRBSmallDictionary and > GlorpSelectCommandTest>>#testExecute. do you know why they fail or how to fix them ? > GlorpTest-DBTests all succeed. ok > GlorpMainBackendTest fails. > > No problem with this one, forget it. > I also had to add NativePostgresDriver>>#externalDatabaseErrorSignal > > externalDatabaseErrorSignal > ^Dialect error > mmm this should be implemented in the accessor, why you need it in the driver? > This also came up during day to day usage and not as a test failure. > > So, for Glorp itself there were no real problems ;-) > great. We should move on Pharo 1.1 > > Maybe just one feature request: on VW NC 7.7 Glorp (when you enable > logging) prints timing info on all queries, on Pharo only for updates and > deletes, which is strange. > > wierd...probaly that's since a lot of time.....if you can digg into the problem, let me know. I can add you as developer if you want. Thanks in advance Mariano > Sven > > On 11 Jun 2010, at 00:32, Mariano Martinez Peck wrote: > > > > > > > On Thu, Jun 10, 2010 at 9:07 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > Mariano, > > > > The fact that you did the port is more than official enough for me ;-) > > > > First, thanks a lot for the port, I know that this must be a lot of work. > > > > I think that Glorp and the different drivers are _very_ important for > many people: talking to an RDBMS is an absolute requirement in almost any > serious application. Without it, Pharo/Seaside becomes almost unusable in > most commercial contexts. Only in some specific cases the other persistency > strategies would be applicable. > > > > Thanks. This is exactly why we did SqueakDBX ;) and then GlorpDBX. > > > > > > I would very much like to help in making the Glorp+PostgreSQL combination > easy to use in Pharo. Writing a ConfigurationOf.. is a bit to much for me > right now though. > > > > > > Great. So, at least, we should make it work, then we see how to load it. > > > > > > > > Concerning my changes, I can send them to you, or save modified versions > of the packages where you want. BTW, I was working on Pharo 1.0 > > > > mmmmm I thought Glorp was already working in 1.0. Weird...which are the > changes? yes, please send me your changes. We have committed Glorp packages > in SqueakDBX repository as we have been changing a lot of things. A big > refactor to Glorp in order to support multiple database drivers. > > > > You can send me the changes or commit them to the packages that are in > SqueakDBX repository at least. I am not sure in Glorp original repository, > but at least in SqueakDBX repository for sure: > http://www.squeaksource.com/SqueakDBX > > > > Please, run all the tests before comitting. > > > > Cheers > > > > Mariano > > > > > > > > Should we continue this discussion over the mailing list or privately ? > > > > Sven > > > > > > > > > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

June 12, 2010

Re: [Pharo-users] Priority of WeakArray finalizationProcess

by StÃ©phane Ducasse

thanks for this report. Yes if you can add a bug report this would be great. Stef On Jun 12, 2010, at 9:16 PM, Joachim Geidel wrote: > While testing JNIPort on Pharo 1.0 and Pharo 1.1, I noticed that in Pharo > 1.0, a JVM (a wrapper object for the Java Virtual Machine) could be > initialized in ca. 4 seconds, while this needed 11 to 12 seconds in Pharo > 1.1. When I profiled the JVM startup in 1.1, the profile reported that less > than 20% of the time was spent there; the rest was not accounted for in the > report. > > In Squeak 4.1, I encountered a deadlock problem related to Squeak's current > WeakRegistry implementation when the JVM is started. This problem > disappeared when I changed the finalizationProcess of WeakArray such that it > runs at systemBackgroundPriority instead of userBackgroundPriority. > > Applying the same change to Pharo 1.1 makes a big difference. The JVM starts > in 4.4 seconds, approximately matching the time it takes in Pharo 1.0. > > Starting the JVM in Squeak 4.1 is about 20% faster than Pharo 1.1. As the > difference is in the part which is not accounted for by the time profiler, > it is probably due to the differences in the implementation of > WeakIdentityKeyDictionary which have an impact on the performance of the > finalizationProcess. > > I am not sure if changing the priority of the finalizationProcess could > possibly break something, and I also do not yet understand why changing the > priority makes such a big difference both in Squeak and Pharo. > > How should this issue be handled? Should I add this as issues to the bug > tracking tools for Pharo and Squeak respectively? > > Cheers, > Joachim Geidel > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

June 12, 2010

Priority of WeakArray finalizationProcess

by Joachim Geidel

While testing JNIPort on Pharo 1.0 and Pharo 1.1, I noticed that in Pharo 1.0, a JVM (a wrapper object for the Java Virtual Machine) could be initialized in ca. 4 seconds, while this needed 11 to 12 seconds in Pharo 1.1. When I profiled the JVM startup in 1.1, the profile reported that less than 20% of the time was spent there; the rest was not accounted for in the report. In Squeak 4.1, I encountered a deadlock problem related to Squeak's current WeakRegistry implementation when the JVM is started. This problem disappeared when I changed the finalizationProcess of WeakArray such that it runs at systemBackgroundPriority instead of userBackgroundPriority. Applying the same change to Pharo 1.1 makes a big difference. The JVM starts in 4.4 seconds, approximately matching the time it takes in Pharo 1.0. Starting the JVM in Squeak 4.1 is about 20% faster than Pharo 1.1. As the difference is in the part which is not accounted for by the time profiler, it is probably due to the differences in the implementation of WeakIdentityKeyDictionary which have an impact on the performance of the finalizationProcess. I am not sure if changing the priority of the finalizationProcess could possibly break something, and I also do not yet understand why changing the priority makes such a big difference both in Squeak and Pharo. How should this issue be handled? Should I add this as issues to the bug tracking tools for Pharo and Squeak respectively? Cheers, Joachim Geidel

June 12, 2010

Re: [Pharo-users] Using Pharo 1.1

by StÃ©phane Ducasse

> But again, that is *only* if you want to track the latest developments, > the common is you take a given vesion, develop your app in there, and > when you have a release, take a new pharo version, update it, load your > code, run your tests and deploy :) yes this model stresses you less. And you can give feedback at check points and we can integrate potential issues that you discover when you tried to migrate from one chekc point to the other. Stef

June 11, 2010

Re: [Pharo-users] Alien for Squeak 4.1/Pharo 1.1?

by StÃ©phane Ducasse

>>>>> >>>> >>>> can you point us to them? > > I had a look at Alien-Prereqs and Alien-Core. Actually, it seems that all > extensions to system classes except the conversion and utility methods can > be removed in all three platforms. The only exception is > Parser>>pragmaStatement. It is needed in Pharo 1.0, which contains an old > version of that method. we will probably then integrate the parser changes. > > I have added a comment to Pharo issue #1360 > (http://code.google.com/p/pharo/issues/detail?id=1360) with attached > Monticello versions of Pharo-Prereqs and Pharo-Core which are compatible > with Pharo 1.0, 1.1, and Squeak 4.1. Pharo-Prereqs is only needed in Pharo > 1.0. The Alien tests were green on all three platforms. > > I have accidentally published Alien-Core to SqueakSource, but have asked > John McIntosh to delete the version. I think that my changes should be > reviewed by someone with better knowledge of Alien and who knows how to > update the ConfigurationOfAlien, before they are released publicly. Sorry > for the inconvinience, I will be more careful next time. > > Best regards, > Joachim Geidel > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

June 11, 2010

Re: [Pharo-users] WebClient

by StÃ©phane Ducasse

Hi sven > Hi, > > Andreas Raab's 'new' WebClient/WebServer seems quite nice, as he says himself: > > As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in every respect. > > Is this something that will / should fit seamlessly into Pharo ? Or even become preinstalled ? could be but not at the price to have concatenation of string and numbers. So this means that somebody would have to do a pass on the code and produce a pharo version that squeakers may want or not. > I didn't try his ConfigurationOfWebClient since the last version was unreadable and it seemed like an experiment, while his textual explanation was easy to follow. > > To load it into and to make the unit tests run in Pharo 1.0 I had to make a couple of fixes (to WebCookie#printOn: and WebServer class#serverString). Who should I sent these changes to ? to andreas? may be ask him if he wants to have a version working also for pharo but without String#, override > But even then 1 unit test failed (#testServerDestroy). > > Furthermore, some the changes in his package WebClient-Pharo seem a bit dangerous, especially a modification to SocketStream#peek (and the failed test was doing a peek) and an override of String#, some others are unneccessary as far as I can see. > > Sven > > -- > Sven Van Caekenberghe - mailto:sven@beta9.be > Beta Nine - software engineering - http://www.beta9.be > .Mac - svc(a)mac.com - http://homepage.mac.com/svc > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

June 11, 2010

Re: [Pharo-users] Glorp & PostgresV2

by Sven Van Caekenberghe

Mariano, I had to change PGConnection class>>#timestampWithTimezoneConverter otherwise it wouldn't want to parse my timestamp with time zone colums that look like '2010-06-16 00:01:00+02' (no millis to skip, no minutes in the offset). Now, my fix is a bit dirty, because it assumes that what I see on my system is the rule while it probably isn't. timestampWithTimezoneConverter ^[ :s | | direction offset | direction := (s at: 20) = $- ifTrue: [ -1 ] ifFalse: [ 1 ]. offset := Duration hours: (s copyFrom: 21 to: 22) asInteger * direction. DateAndTime year: (s copyFrom: 1 to: 4) asInteger month: (s copyFrom: 6 to: 7) asInteger day: (s copyFrom: 9 to: 10) asInteger hour: (s copyFrom: 12 to: 13) asInteger minute: (s copyFrom: 15 to: 16) asInteger second: (s copyFrom: 18 to: 19) asInteger offset: offset ] I can definitively write a better version that handles different kinds of formats in a flexible way. I also think the #copyFrom:to:'s are waistful and could at least be replaced with ReadStream>>#on:from:to:'s. This goes for some other converters as well. This code is execute for each column so seems resource critical. This change did not come up as a failed unit test, so maybe I should also try to add one ? On my Pharo 1.0 image, all PGConnection tests pass. Of the 844 GlorpTest tests, 2 fail: GlorpRowMapForMementosCollectionTest>>#testRBSmallDictionary and GlorpSelectCommandTest>>#testExecute. GlorpTest-DBTests all succeed. GlorpMainBackendTest fails. I also had to add NativePostgresDriver>>#externalDatabaseErrorSignal externalDatabaseErrorSignal ^Dialect error This also came up during day to day usage and not as a test failure. So, for Glorp itself there were no real problems ;-) Maybe just one feature request: on VW NC 7.7 Glorp (when you enable logging) prints timing info on all queries, on Pharo only for updates and deletes, which is strange. Sven On 11 Jun 2010, at 00:32, Mariano Martinez Peck wrote: > > > On Thu, Jun 10, 2010 at 9:07 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Mariano, > > The fact that you did the port is more than official enough for me ;-) > > First, thanks a lot for the port, I know that this must be a lot of work. > > I think that Glorp and the different drivers are _very_ important for many people: talking to an RDBMS is an absolute requirement in almost any serious application. Without it, Pharo/Seaside becomes almost unusable in most commercial contexts. Only in some specific cases the other persistency strategies would be applicable. > > Thanks. This is exactly why we did SqueakDBX ;) and then GlorpDBX. > > > I would very much like to help in making the Glorp+PostgreSQL combination easy to use in Pharo. Writing a ConfigurationOf.. is a bit to much for me right now though. > > > Great. So, at least, we should make it work, then we see how to load it. > > > > Concerning my changes, I can send them to you, or save modified versions of the packages where you want. BTW, I was working on Pharo 1.0 > > mmmmm I thought Glorp was already working in 1.0. Weird...which are the changes? yes, please send me your changes. We have committed Glorp packages in SqueakDBX repository as we have been changing a lot of things. A big refactor to Glorp in order to support multiple database drivers. > > You can send me the changes or commit them to the packages that are in SqueakDBX repository at least. I am not sure in Glorp original repository, but at least in SqueakDBX repository for sure: http://www.squeaksource.com/SqueakDBX > > Please, run all the tests before comitting. > > Cheers > > Mariano > > > > Should we continue this discussion over the mailing list or privately ? > > Sven > > > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

June 11, 2010

Re: [Pharo-users] Glorp & PostgresV2

by Mariano Martinez Peck

On Thu, Jun 10, 2010 at 9:07 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Mariano, > > The fact that you did the port is more than official enough for me ;-) > > First, thanks a lot for the port, I know that this must be a lot of work. > > I think that Glorp and the different drivers are _very_ important for many > people: talking to an RDBMS is an absolute requirement in almost any serious > application. Without it, Pharo/Seaside becomes almost unusable in most > commercial contexts. Only in some specific cases the other persistency > strategies would be applicable. > Thanks. This is exactly why we did SqueakDBX ;) and then GlorpDBX. > > I would very much like to help in making the Glorp+PostgreSQL combination > easy to use in Pharo. Writing a ConfigurationOf.. is a bit to much for me > right now though. > Great. So, at least, we should make it work, then we see how to load it. > > Concerning my changes, I can send them to you, or save modified versions of > the packages where you want. BTW, I was working on Pharo 1.0 > mmmmm I thought Glorp was already working in 1.0. Weird...which are the changes? yes, please send me your changes. We have committed Glorp packages in SqueakDBX repository as we have been changing a lot of things. A big refactor to Glorp in order to support multiple database drivers. You can send me the changes or commit them to the packages that are in SqueakDBX repository at least. I am not sure in Glorp original repository, but at least in SqueakDBX repository for sure: http://www.squeaksource.com/SqueakDBX Please, run all the tests before comitting. Cheers Mariano > > Should we continue this discussion over the mailing list or privately ? > > Sven > > > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

June 10, 2010

Pharo book TableLayout tutorial

by laurent laffont

Hi, I've added a tutorial on TableLayout http://book.pharo-project.org/book/GUI/PolymorphTutorial/TableLayout/ which follows the one on Proportional Layout. Again, thanks for feedback and English check. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

June 10, 2010

Re: [Pharo-users] Glorp & PostgresV2

by Sven Van Caekenberghe

Mariano, The fact that you did the port is more than official enough for me ;-) First, thanks a lot for the port, I know that this must be a lot of work. I think that Glorp and the different drivers are _very_ important for many people: talking to an RDBMS is an absolute requirement in almost any serious application. Without it, Pharo/Seaside becomes almost unusable in most commercial contexts. Only in some specific cases the other persistency strategies would be applicable. I would very much like to help in making the Glorp+PostgreSQL combination easy to use in Pharo. Writing a ConfigurationOf.. is a bit to much for me right now though. Concerning my changes, I can send them to you, or save modified versions of the packages where you want. BTW, I was working on Pharo 1.0 Should we continue this discussion over the mailing list or privately ? Sven

June 10, 2010