- Pharo-users - lists.pharo.org

Re: [Pharo-users] Parsing SQL in a Pharo system

by Stephan Eggermont

PostgresV3-Core/Pool looks perfectly usable. There is PG3Connection>>md5HashMessage: aString ^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ WebUtils md5Digest: aString ] Which works in Pharo 4, though WebUtils doesn't exist anymore. Replacing it is trivial md5HashMessage: aString ^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ (Smalltalk globals at: #WebUtils) md5Digest: aString ] Stephan

Oct. 3, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Pierce Ng

On Thu, Oct 02, 2014 at 03:43:05PM -0300, Esteban A. Maringolo wrote: > Is the V2/V3 spec a PostgreSQL protocol spec or something made up in > the Squeak community? V2/V3 are PostgreSQL wire protocol versions. V3 supports parameter binding and bulk copying, whereas V2 does not. There is some additional info at this squeak-dev thread: http://forum.world.st/Status-of-PostgresV3-td4780110.html Looking at the updated packages, there seems to be support in PostgresV3 (here meaning the Smalltalk software) for parameter binding at the protocol level, but the API does not provide any facility to use it. Pierce

Oct. 3, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by stepharo

On 2/10/14 23:37, Esteban Lorenzano wrote: > HI, > > Well, what you say sounds harsh... but is not too far from truth, > sadly. What happens is that current manpower for every task is very > limited (it's me)... and well, urgent stuff is always hunting us. But esteban this is not true. Pharo is not you sorry. Pharo is OURS. > We have the willing, and we have spent some time on it, but it will be > a lot easier if there is also community effort put on improve > things... every single bugfix, comment or whatever helps, but also > more important efforts are needed. > > We would bless any effort/collaboration in that direction. I suppose > we can also put bounties to fulfil certain tasks (that's how first > DBXTalk suite was made). > To have a description of what we need (a list of features, etc.) would > be cool too. exactly! I alwys thought that improving the infrastructure was magically done. This is not the case? Santa claus is a lie. How sad. Stef > > > > >

Oct. 3, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by stepharo

On 2/10/14 20:43, Esteban A. Maringolo wrote: > I don't want to sound harsh, but there is no VISIBLE interest from the > Pharo board/committee regarding ORM and/or RDBMS support other than a > CI task. Do you really mean that the board is a kind of jerks and idiots that are lazy bastards? If people that have interest in ORM do not help us how can make progress. When did you send a fix to Pharo? Remember Pharo is Yours. Esteban is working like a mad on making sure that Spur is coming to us. May be we can say to esteban to stop Spur and 64 bits after and some VM bug fix and support for integrating better and .... to focus on Glorp and DBTalk. Now when as a community did we help the consortium, the board and the community? > Few days ago I asked a question in the Pharo-Business > regarding this, and got NO REPLY. I did not see it. > > This week I was looking into Python's SQLAlchemy [1] to find how close > it is to GLORP current features, and also found out how far it > seems/feels to a small > community like ours. Not to mention things like jOOQ[2] ([1] provides > some of its features though). > > I'm making no demands here, just giving my opinion about a "business > feature" (DBs) that I'd like better supported. This is on our roadmap. With the money of the consrortium I hope that we will be able to pay someone (I have an idea) to improve this support but there is no magic - if people that needs it do not give an hand.... - if people that needs it do not participate to the consortium then it will be at our speed. Because other Pharo clients like Thales wants multi windowing support, we need better Text, better events .... May pythoners are cooler than Pharoers when it comes to helping write code and documentation? > >> And I wondered why SqueakDBX decided to use V2 instead of V3, >> a protocol introduced in 2003 or so. > Is the V2/V3 spec a PostgreSQL protocol spec or something made up in > the Squeak community? > I know something changed in PgSQL protocols around version 7.2. > > > Esteban A. Maringolo > [1] http://www.sqlalchemy.org/ > [2] http://www.jooq.org/ > >

Oct. 3, 2014

Re: [Pharo-users] "Conceptually the same as" in Smalltalk

by Alexandre Bergel

Hi Sean, This is a complex question. Essentially, this is the difference between a plain normal class and an abstract data type. Abstract data type will typically override hash and = to give the ability to structurally compare them. >From my rather long experience in programming, I do not remember to have overriding = and hash, even once. This is error prone and not justified. Also, if you have two different objects that are equals, then it often leads to complex situation to debug (Have you ever used âTranscript show: my object hash asStringâ?). In your case of Person, I guess each person has to have a unique Id (social number?). This is how I would solve this. Cheers, Alexandre On Oct 2, 2014, at 4:41 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I've read that #= can ignore non-domain things like cache data, but what > about domain-related things that do not effect identity? > > Let's say I have a Person class. Obviously, the #name would be compared in > #=. But what if there was a collection of #phoneNumbers, and aPerson and > anotherPerson differed only in that one of them had been updated with an > extra #phoneNumber? Should #= answer true or false? I'm guessing true since > e.g. in a unique collection there should only be one of that particular > person. Then there would have to be another message like #exactlyTheSameAs:. > Is there a well-known pattern distinguishing "Conceptually the same as" from > "exactly the same as, but not #=="? > > Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Conceptually-the-same-as-in-Smalltalk-tp4782118.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Esteban Lorenzano

HI, Well, what you say sounds harsh... but is not too far from truth, sadly. What happens is that current manpower for every task is very limited (it's me)... and well, urgent stuff is always hunting us. We have the willing, and we have spent some time on it, but it will be a lot easier if there is also community effort put on improve things... every single bugfix, comment or whatever helps, but also more important efforts are needed. We would bless any effort/collaboration in that direction. I suppose we can also put bounties to fulfil certain tasks (that's how first DBXTalk suite was made). To have a description of what we need (a list of features, etc.) would be cool too. cheers, Esteban On Thu, Oct 2, 2014 at 10:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Esteban, > > On 02 Oct 2014, at 20:43, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 2014-10-02 15:19 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > >> Esteban wrote: > >>> Are you using/planning to use PostgresV3? > >> > >>> What are its advantages over current driver (PostgresV2)? > >> > >> I was puzzled that a smart developer like Levente > >> decides not to use Glorp. > > > > I don't want to sound harsh, but there is no VISIBLE interest from the > > Pharo board/committee regarding ORM and/or RDBMS support other than a > > CI task. Few days ago I asked a question in the Pharo-Business > > regarding this, and got NO REPLY. > > > > This week I was looking into Python's SQLAlchemy [1] to find how close > > it is to GLORP current features, and also found out how far it > > seems/feels to a small > > community like ours. Not to mention things like jOOQ[2] ([1] provides > > some of its features though). > > > > I'm making no demands here, just giving my opinion about a "business > > feature" (DBs) that I'd like better supported. > > I understand your pain, you're looking for people that are in the same > boat, apparently there aren't that many. But there certainly are some (I > use(d) Glorp+PostgresV2 myself, I believe Mariano does too), but it seems > nobody wants to take the lead to push this (even) further. I am not sure > this is necessarily bad, RDBMS does not move that much, but it would > obviously be better to have more users. > > We are a small(er) community, it is what it is, but we are growing. > > >> And I wondered why SqueakDBX decided to use V2 instead of V3, > >> a protocol introduced in 2003 or so. > > > > Is the V2/V3 spec a PostgreSQL protocol spec or something made up in > > the Squeak community? > > I know something changed in PgSQL protocols around version 7.2. > > V2 and V3 are indeed two different wire level protocols for a DB client to > talk to PostgreSQL. Obviously, V3 came after V2, it should be considered an > improvement, but V2 remains supported. As far as I understood it, V3 is > binary while V2 is text oriented, the former should be faster. I am sure > there are feature lists comparing the two somewhere out there. > > Of course, the implementation quality of the driver is important too to > get good performance. > > We'll see how far Stephan gets, I am interested. I really hope we can get > the V3 code running in Pharo without too much compatibility issues. > > > Esteban A. Maringolo > > [1] http://www.sqlalchemy.org/ > > [2] http://www.jooq.org/ > > Sven > > >

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Sven Van Caekenberghe

Esteban, On 02 Oct 2014, at 20:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-10-02 15:19 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >> Esteban wrote: >>> Are you using/planning to use PostgresV3? >> >>> What are its advantages over current driver (PostgresV2)? >> >> I was puzzled that a smart developer like Levente >> decides not to use Glorp. > > I don't want to sound harsh, but there is no VISIBLE interest from the > Pharo board/committee regarding ORM and/or RDBMS support other than a > CI task. Few days ago I asked a question in the Pharo-Business > regarding this, and got NO REPLY. > > This week I was looking into Python's SQLAlchemy [1] to find how close > it is to GLORP current features, and also found out how far it > seems/feels to a small > community like ours. Not to mention things like jOOQ[2] ([1] provides > some of its features though). > > I'm making no demands here, just giving my opinion about a "business > feature" (DBs) that I'd like better supported. I understand your pain, you're looking for people that are in the same boat, apparently there aren't that many. But there certainly are some (I use(d) Glorp+PostgresV2 myself, I believe Mariano does too), but it seems nobody wants to take the lead to push this (even) further. I am not sure this is necessarily bad, RDBMS does not move that much, but it would obviously be better to have more users. We are a small(er) community, it is what it is, but we are growing. >> And I wondered why SqueakDBX decided to use V2 instead of V3, >> a protocol introduced in 2003 or so. > > Is the V2/V3 spec a PostgreSQL protocol spec or something made up in > the Squeak community? > I know something changed in PgSQL protocols around version 7.2. V2 and V3 are indeed two different wire level protocols for a DB client to talk to PostgreSQL. Obviously, V3 came after V2, it should be considered an improvement, but V2 remains supported. As far as I understood it, V3 is binary while V2 is text oriented, the former should be faster. I am sure there are feature lists comparing the two somewhere out there. Of course, the implementation quality of the driver is important too to get good performance. We'll see how far Stephan gets, I am interested. I really hope we can get the V3 code running in Pharo without too much compatibility issues. > Esteban A. Maringolo > [1] http://www.sqlalchemy.org/ > [2] http://www.jooq.org/ Sven

Oct. 2, 2014

"Conceptually the same as" in Smalltalk

by Sean P. DeNigris

I've read that #= can ignore non-domain things like cache data, but what about domain-related things that do not effect identity? Let's say I have a Person class. Obviously, the #name would be compared in #=. But what if there was a collection of #phoneNumbers, and aPerson and anotherPerson differed only in that one of them had been updated with an extra #phoneNumber? Should #= answer true or false? I'm guessing true since e.g. in a unique collection there should only be one of that particular person. Then there would have to be another message like #exactlyTheSameAs:. Is there a well-known pattern distinguishing "Conceptually the same as" from "exactly the same as, but not #=="? Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Conceptually-the-same-as-in-Smalltalk-tp4782118.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 2, 2014

Re: [Pharo-users] BLOG: Block Translators - parsing magic

by Udo Schneider

On 02.10.14 18:17, Damien Cassou wrote: > you should have received an invitation Yepp - I did. Already committed the Blog entry 1:1. Working on cleaning up the language now. BTW: Is there any guide regarding the kind of language (e.g. tonality) of the book. I'd change the it given the fact that the blog entry is pretty informal which is IMHO not appropriate for a book ... Thanks, Udo

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Esteban A. Maringolo

2014-10-02 15:19 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > Esteban wrote: >>Are you using/planning to use PostgresV3? > >>What are its advantages over current driver (PostgresV2)? > > I was puzzled that a smart developer like Levente > decides not to use Glorp. I don't want to sound harsh, but there is no VISIBLE interest from the Pharo board/committee regarding ORM and/or RDBMS support other than a CI task. Few days ago I asked a question in the Pharo-Business regarding this, and got NO REPLY. This week I was looking into Python's SQLAlchemy [1] to find how close it is to GLORP current features, and also found out how far it seems/feels to a small community like ours. Not to mention things like jOOQ[2] ([1] provides some of its features though). I'm making no demands here, just giving my opinion about a "business feature" (DBs) that I'd like better supported. > And I wondered why SqueakDBX decided to use V2 instead of V3, > a protocol introduced in 2003 or so. Is the V2/V3 spec a PostgreSQL protocol spec or something made up in the Squeak community? I know something changed in PgSQL protocols around version 7.2. Esteban A. Maringolo [1] http://www.sqlalchemy.org/ [2] http://www.jooq.org/

Oct. 2, 2014