October 2014 - Pharo-users - lists.pharo.org

Official academic consortium members

by stepharo

Hi guys we are really happy to welcome University of Bern Uqbar Reveal from Lugano as official academic member of the pharo consortium. I know that some other entities are following the same path and this is really great. Stef

Oct. 3, 2014

Alien could not load library

by Annick Fron

Hi, I have built my own linux dynamic library to use with FFI and Alien. Up to now, everything was OK but I made some changes, and now I am unable to load the library. The compilation was OK. I have checked with ldd the dependencies, and I have loaded the dependent libraries with : Alien ensureLoaded: dependentLib But I have still the problem. Annick

Oct. 3, 2014

Re: [Pharo-users] Versioneer. nice. mmMmmm...

by Christophe Demarey

Hi Kilon, Le 30 sept. 2014 Ã 15:53, kilon alios a Ã©crit : > Actually the best thing to do when you 2 choices is to pick the third one. In this case its what I call "double mode" , you see it quite frequently with software synthesizer, as you can imagine a synthesizer is a complex electronic music instrument that can reach up to thousand of parameters easily so what designers have done is to create an easy mode and an advanced mode. In easy mode is for those that want to create sounds on the go, usually that means around 10-30 parameters buttons and advanced mode is divided into panels that can expanded collapse to control the complexity of the GUI that may contain even thousands of parameters. > > GUI design is a science and an art but yes you can have your cake and eat it too. > > I think with Versioner we can keep it small for now and then if it get a bit more complex go for a double mode. > > About collaboration if you are familiar with git and github then nothing can beat this workflow . You create a repo in gihub, I fork it, and I then send pull requests to you, pull requests do not affect your code and you can choose what to merge and not to merge giving you complete control and me the safety that I wont brake anything. You can also comment the code directly using github web interface and of course the issue tracker for any issue that may be reported. If you are not familiar with git or dont want to us it , I have no issues committing to smalltalkhub , I will create a mirror repo in github anyway for my work since this is how I work when it comes to my Pharo projects. > > The choice is your, I will now start studying the code and see what I can bring to it. Sorry for the delay. I was about to move Versionner to git but finally, I prefer to wait a bit before switching. I cleaned up Versionner repository, i.e. give right package names so that we can easily catch branches. I think it will be the best way to collaborate for now: commit in a branch in the current repository on SmalltalkHub. Please, create a new branch for your contributions, and ping me if you have something to show or if you need help. Best regards, Christophe.

Oct. 3, 2014

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

by Stephan Eggermont

PostgresV3-CodeMirror is very interesting. 7 classes and less than 1K lines of code. In the base class PG3SchemaMirror, the compilerClass, parserClass, sourceCodeTemplate and shoutParserClass are overridden to return PG3-specific classes. That allows simple integration with other languages, in this case plsql. In Pharo we don't have shoutParserClass defined on Behavior. Where do I set what highlighter is to be used for a method? Stephan

Oct. 3, 2014

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

by Esteban A. Maringolo

2014-10-02 17:26 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > 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. The quid here is who takes the lead, I said I could contribute and code, but taking the lead on a project requires more than coding skills. The point that RDBMS is a stable thing a benefit in this case, and that's why those who use GLORP today (like me), only got bitten by a few bugs due to an outdated port. And as long as we use PostgreSQL we'll be in the safer zone. >> 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. I haven't reached any limits of the V2 driver yet. If I have a bottleneck it is down the DB or at the app level. Thank you!

Oct. 3, 2014

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

by Esteban A. Maringolo

2014-10-03 2:47 GMT-03:00 stepharo <stepharo(a)free.fr>: > 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? Please slow down, I never, ever, suggested even remotely that. I said there is no VISIBLE interest. In the latest Consortium Report it isn't even listed. It's not a topic that attracts interest as Spec and other things does. > 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. I use it daily for my business, which on some aspects of its technology stack like DB feels more like a bet than a safe decision. I submitted a few commits to GLORP and PostgresV2 packages, does that count? > 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. I know, and I understand the priorities given the limited manpower. That's why I mentioned I was making no demands, I was simply giving my opinion. > 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. Sept 30, subject "Better ORM tools/alternatives" >> 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. Not in https://github.com/pharo-project/pharo-workingRoadmaps. > 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 .... Please don't excuse yourself or the consortium, there is no need, I understand what it is to have a big backlog and a limited manpower/money to tackle all of it in a short time. > May pythoners are cooler than Pharoers when it comes to helping write code > and documentation? I have no idea, I don't participate in any Python community. But please consider that accusing me (or anybody) of treating you as jerks or suggesting that if I don't send fixes I shouldn't emit opinions is totally discouraging. I know you're passionate and you live&love Pharo, and hence you speak that way, and I can understand that, but even if I understand who, how and why you're saying something it somehow hurts the feeling of belonging to the community (to which I feel part of). Best regards!

Oct. 3, 2014

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