- Pharo-dev - lists.pharo.org

Re: [Pharo-project] TextMorph: what is the purpose of predecessor/successor?

by Alain Plantec

I forgot to say that I think we should simplify TextMorph as much as possible. I've already removed predecessor/successsor some time ago for my own textmorph fork. I open an isssue Alain Le 11/11/2011 10:38, Igor Stasenko a Ã©crit : > Thanks. > Yes, i remember i seen this before, but i had no idea how it implemented. > > On 10 November 2011 18:36, Alain Plantec<alain.plantec(a)yahoo.com> wrote: >> Hi Igor, >> See the screenshot (Squeak 3.6). >> You can have several morphs editing the same text. >> Each morph containing its own part of the text. >> I guess predecessor ans successor are used in this context. >> Cheers >> >> Alain >> >> Le 10/11/2011 16:50, Igor Stasenko a Ã©crit : >>> looks like the purpose is to make multiple morphs, displaying >>> different (but adjacent) portions of one text.. >>> >>> But what i don't understand is what is the practical use of it? Is >>> there an examples of such use of TextMorph(s)? >>> As to me this looks a bit of over-enineering: >>> morph represents a view of some model. >>> Nothing prevents us from creating multiple different views of same >>> model (a text in this case). And i don't get, what do we gain by >>> letting them know about each other. >>> If there is a need to have a coordination between views, i think it >>> would be much simpler to have some centralized parent object/morph, >>> which managing additional complexity related with such >>> composition. >>> >>> >>> The functionality seems to be working: >>> in text morph's halo, click on its menu , and there will be >>> 'add predecessor' >>> and >>> 'add successor' >>> menu items, which creating a fresh text morphs over same text and put >>> it in ?hand? >>> >>> i am clueless, what is purpose of this and whether it belongs to right >>> place.. that's why i asking. >>> (i would just throw it away ;) >>> >> > >

Nov. 11, 2011

Re: [Pharo-project] Accessing the OS Environment Variables

by Alberto Bacchelli

Thank you! It works perfectly :) Sean P. DeNigris wrote: > > Or with OSProcess: "OSProcess thisOSProcess environment" > -- View this message in context: http://forum.world.st/Accessing-the-OS-Environment-Variables-tp4024106p4031… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 11, 2011

[Pharo-project] [update 1.4] #14224

by Marcus Denker

14224 ----- Issue 4981: New implementation of process-specific storage http://code.google.com/p/pharo/issues/detail?id=4981 Issue 4960: Fix openInWorld method http://code.google.com/p/pharo/issues/detail?id=4960 Issue 4980: UUID>>< has a halt http://code.google.com/p/pharo/issues/detail?id=4980 -- Marcus Denker -- http://marcusdenker.de

Nov. 11, 2011

Re: [Pharo-project] [FOSDEM 2012] Devroom accepted: Smalltalk, Sunday 2012-2-5, Brussels

by Marcus Denker

On Nov 11, 2011, at 6:29 AM, Stephan Eggermont wrote: > Dear Smalltalking Friends, > > Please tell me what you'd like to happen there. > We have a good opportunity to show why we > believe in smalltalk. > Very nice! I will come and I can give demos or presentations. In the past people tried to get a slot at FOSDEM and it never worked out, so it's great that you managed to get it! Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 11, 2011

Re: [Pharo-project] Icon for commented/uncommented classes

by Mariano Martinez Peck

I would like to have that in the browser also :) On Wed, Nov 9, 2011 at 4:19 PM, Milan Mimica <milan.mimica(a)gmail.com> wrote: > In Pharo 1.4, class comments are always visible when looking at the class > definition. So it does expose the comment more, asking you to write one. > > > 2011/11/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > >> Hi guys, >> >> It would be very nice to visualy indicate in browser when some class has >> comment, or even better, when not. This is good for many reasons: >> >> - you know where to read comments and where is not worth trying >> - authors are encouraged to write those comments, to increase >> reputation avoid having too much that ! icons near not commented >> classes >> >> Also the ? button in browser should be red if there is no comment. >> >> This can be disabled in settings but by default it should be enabled. >> >> Best regards >> Janko >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> > > > -- > Milan Mimica > http://sparklet.sf.net > -- Mariano http://marianopeck.wordpress.com

Nov. 11, 2011

Re: [Pharo-project] GlorpDBX PostgreSQL Patch

by Guillermo Polito

On Fri, Nov 11, 2011 at 8:16 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. I am trying to understand how to integrate this in the OpenDBX > driver, but I am a little bit lost. > First, I don't understand when this #byteArrayToSQLStringConverter is > used. What is the bytearray and what is the string? one is the database > type and the other one is the inst var of one you your mapping class? > This is because the conversion is being done right now in glorp... We are already performing conversions in OpenDBX, but they are not platform specific conversions, since we handle only ANSI conversions ;). Maybe we can build a PostgreSQLOpenDBXDriver (?) > > Second, I don't know WHERE to put such conversion in the OpenDBX driver. > Why it should be there if #convertSQLStringToByteArray: aString for: aType > will continue to exist in Glorp. So it means I should also modify Glorp? > > How does the EXDI driver of VW work here? > > Thanks! > > > On Thu, Nov 10, 2011 at 11:15 AM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> On 10.11.2011 14:29, Sven Van Caekenberghe wrote: >> >>> Alan, >>> >>> On 09 Nov 2011, at 21:20, Alan Knight wrote: >>> >>> My inclination would be to think that this is something that the >>>> database driver ought to be handling rather than having it in Glorp at all. >>>> But, given that it's in there, I suppose it's not unreasonable. >>>> >>> Well, I just extended the previous conversion that was already located >>> there. I did not consider whether or not that kind of platform specific >>> code was in its right place, architecture wise. >>> >>> So, will it be integrated somewhere ? If it is only integrated in the >>> Pharo/Squeak port that is fine for me too, but it would be frustrating if >>> it got lost on the next upstream integration. >>> >>> I would just love to be able to load the standard release and have it >>> working for me (i.e. loading blobs from a recent PostgreSQL). >>> >>> Thx for the reply, >>> >>> Sven >>> >>> I agree with Alan, it should be in the Postgres-specific code of >> OpenDBX-driver. >> Glorp can't be the only user who wants to read blobs, can it? ;) >> >> Cheers, >> Henry >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- > You received this message because you are subscribed to the Google Groups > "glorp-group" group. > To post to this group, send email to glorp-group(a)googlegroups.com. > To unsubscribe from this group, send email to > glorp-group+unsubscribe(a)googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/glorp-group?hl=en. >

Nov. 11, 2011

[Pharo-project] Plugin to trigger Jenkins build when there are squeaksource commits

by Mariano Martinez Peck

Hi guys. It seems the Jenkins of Pharo is using the plugin "URL Change Trigger <https://wiki.jenkins-ci.org/display/JENKINS/URL+Change+Trigger>" which is deprecated and I cannot install it. The new plugin is URLTrigger Plugin but I don't know how to configure it with SqueakSource. Do you know? does it work? Thanks -- Mariano http://marianopeck.wordpress.com

Nov. 11, 2011

Re: [Pharo-project] GlorpDBX PostgreSQL Patch

by Henrik Sperre Johansen

On 11.11.2011 13:00, Henrik Sperre Johansen wrote: > On 11.11.2011 12:16, Mariano Martinez Peck wrote: >> Hi guys. I am trying to understand how to integrate this in the >> OpenDBX driver, but I am a little bit lost. >> First, I don't understand when this #byteArrayToSQLStringConverter is >> used. What is the bytearray and what is the string? one is the >> database type and the other one is the inst var of one you your >> mapping class? >> > Yes. > Blobs in Postgres-SQL is basically byteStrings, where a single byte > can be encoded in one of two ways: > - Raw with some escaped > - As a hex string > > So the method should be used by the driver when asked to store a > (smalltalk) byteArray into a (postgres) blob column. > >> Second, I don't know WHERE to put such conversion in the OpenDBX >> driver. Why it should be there if #convertSQLStringToByteArray: >> aString for: aType will continue to exist in Glorp. So it means I >> should also modify Glorp? > Yes, it should be removed from Glorp. > If you want to store bytearrays to blobs in different backend > databases (or same backend, but different drivers), converting from > smalltalk object to what the database stores has to be the job of the > driver. > Otherwise, you might end up double-encoding in some cases, if both > Glorp and Driver does the conversion, > and if not in driver, duplicate the conversion in any users of the > driver if they are to work correctly. > >> >> How does the EXDI driver of VW work here? > > Driver takes care of conversion. > Does not currently support hex-string format though. > > Cheers, > Henry > > Read the above as applicable to both storing/reading blobs to/from the database, not just one of the cases :) Cheers, Henry

Nov. 11, 2011

Re: [Pharo-project] GlorpDBX PostgreSQL Patch

by Henrik Sperre Johansen

On 11.11.2011 12:16, Mariano Martinez Peck wrote: > Hi guys. I am trying to understand how to integrate this in the > OpenDBX driver, but I am a little bit lost. > First, I don't understand when this #byteArrayToSQLStringConverter is > used. What is the bytearray and what is the string? one is the > database type and the other one is the inst var of one you your > mapping class? > Yes. Blobs in Postgres-SQL is basically byteStrings, where a single byte can be encoded in one of two ways: - Raw with some escaped - As a hex string So the method should be used by the driver when asked to store a (smalltalk) byteArray into a (postgres) blob column. > Second, I don't know WHERE to put such conversion in the OpenDBX > driver. Why it should be there if #convertSQLStringToByteArray: > aString for: aType will continue to exist in Glorp. So it means I > should also modify Glorp? Yes, it should be removed from Glorp. If you want to store bytearrays to blobs in different backend databases (or same backend, but different drivers), converting from smalltalk object to what the database stores has to be the job of the driver. Otherwise, you might end up double-encoding in some cases, if both Glorp and Driver does the conversion, and if not in driver, duplicate the conversion in any users of the driver if they are to work correctly. > > How does the EXDI driver of VW work here? Driver takes care of conversion. Does not currently support hex-string format though. Cheers, Henry

Nov. 11, 2011

Re: [Pharo-project] GlorpDBX PostgreSQL Patch

by Mariano Martinez Peck

Hi guys. I am trying to understand how to integrate this in the OpenDBX driver, but I am a little bit lost. First, I don't understand when this #byteArrayToSQLStringConverter is used. What is the bytearray and what is the string? one is the database type and the other one is the inst var of one you your mapping class? Second, I don't know WHERE to put such conversion in the OpenDBX driver. Why it should be there if #convertSQLStringToByteArray: aString for: aType will continue to exist in Glorp. So it means I should also modify Glorp? How does the EXDI driver of VW work here? Thanks! On Thu, Nov 10, 2011 at 11:15 AM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 10.11.2011 14:29, Sven Van Caekenberghe wrote: > >> Alan, >> >> On 09 Nov 2011, at 21:20, Alan Knight wrote: >> >> My inclination would be to think that this is something that the >>> database driver ought to be handling rather than having it in Glorp at all. >>> But, given that it's in there, I suppose it's not unreasonable. >>> >> Well, I just extended the previous conversion that was already located >> there. I did not consider whether or not that kind of platform specific >> code was in its right place, architecture wise. >> >> So, will it be integrated somewhere ? If it is only integrated in the >> Pharo/Squeak port that is fine for me too, but it would be frustrating if >> it got lost on the next upstream integration. >> >> I would just love to be able to load the standard release and have it >> working for me (i.e. loading blobs from a recent PostgreSQL). >> >> Thx for the reply, >> >> Sven >> >> I agree with Alan, it should be in the Postgres-specific code of > OpenDBX-driver. > Glorp can't be the only user who wants to read blobs, can it? ;) > > Cheers, > Henry > > -- Mariano http://marianopeck.wordpress.com

Nov. 11, 2011