November 2011 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] deprecation process

by Marcus Denker

On Nov 10, 2011, at 8:29 PM, Alain Plantec wrote: > Hi all, > I'm reviewing some fixes and I was just wondering: > Do we have to manually move a deprecated method to the > Deprecated14 package or is it done automatically ? Everyting is done by hand. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 11, 2011

Re: [Pharo-project] FS and binary files

by Marcus Denker

On Nov 11, 2011, at 5:38 AM, Lukas Renggli wrote: > I thought it was adopted as part of Pharo 1.4? Or maybe it is just used as part of Coral? > > No clue ... > It's in 1.4... I think Camillo started to change somehing with Streams, this might not be finished. So the best is to file a bug report if something is not working how it should be. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 11, 2011

Re: [Pharo-project] FS and binary files

by Max Leske

Yep, 1.4 AFAIK. Max On 11.11.2011, at 09:37, Lukas Renggli wrote: > I thought it was adopted as part of Pharo 1.4? Or maybe it is just used as part of Coral? > > No clue ... > > Lukas > > On 11 November 2011 08:09, Johannes Rasche <johannesrasche(a)mac.com> wrote: > Thx Lukas, > > I'll try it ... > > anyway I'm wondering about that - > > as FS appeared, I had the impression, that this would be the long awaited replacement of FileDirectory, > > but it doesn't seem so, because it's not part of the official Pharo up to now (1.3), > > or is there another alternative to FileDirectory I've overseen? > > and what do you mean by "Pharo forked the original implementation"? up to 1.3 I cannot see FS > > Johannes > > Am 10.11.11 18:06, schrieb Lukas Renggli: >> Not really, Pharo forked the original implementation. >> >> In Colin's code you had to use the third supported stream type: not #readStream and not #writeStream (that are minimal ANSI compatible streams), but a third kind that I forgot the name of (it would return a RBBinaryReadWriteStream that works with most existing code). >> >> Lukas >> >> On 10 November 2011 16:25, Johannes Rasche <johannesrasche(a)mac.com> wrote: >> Hi Lukas, >> >> you may not have realized the message below. >> >> I assume you might be the person who coud answer my question >> >> Cheers Johannes >> >> -------- Original-Nachricht -------- >> Betreff: [Pharo-project] FS and binary files >> Datum: Wed, 09 Nov 2011 15:36:16 +0100 >> Von: Johannes Rasche <johannesrasche(a)mac.com> >> Antwort an: Pharo-project(a)lists.gforge.inria.fr >> An: pharo-project(a)lists.gforge.inria.fr >> >> >> Hi folks, >> >> I just started to using FS instead of FileDirectory. >> >> On readStream sent to FSReference a FSAnsiiStream turns out, which is >> not suitable for reading images ( for instance with PNGReadWriter). >> >> What did I wrong? >> >> Johannes >> >> >> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch > > > -- > Johannes Rasche Hagelberger Str. 56 10965 Berlin mail johannesrasche(a)mac.com mobile +49 1577 175 04 75 > > > > -- > Lukas Renggli > www.lukas-renggli.ch

Nov. 11, 2011

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

by Igor Stasenko

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 ;) >> > > -- Best regards, Igor Stasenko.

Nov. 11, 2011

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

by Stephan Eggermont

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. I can do a 'Back to the future, (re)learning smalltalk' session. Stephan Begin forwarded message: > From: Pascal Bleser <pbleser(a)fosdem.org> > Date: 10 november 2011 23:58:43 GMT+01:00 > To: Stephan Eggermont <stephan(a)stack.nl> > Cc: devrooms(a)fosdem.org > Subject: [FOSDEM 2012] Devroom accepted: Smalltalk > Reply-To: devrooms(a)fosdem.org > > Hi Stephan > > We've got good news, as we have accepted and planned your > request for a developer room at FOSDEM 2012 for the following > topic/project: Smalltalk > > We will provide you with the following: > - room AW1.126 with 72 seats, > - a video projector (VGA) > - wireless internet, > on Sunday 5th for 8 hours. > > If you prefer to decline this offer, please inform us as soon as > possible. > > We must add that as in previous years, visitor interest will > outnumber room capacity for most devrooms. We can not offer you > larger rooms -- instead we will provide you with signalization > to indicate that the room is full. > > We will have more rooms in total as compared to previous > editions, so hopefully that will balance the crowd across the > various areas of the venue. > > Regarding content and format, you are free to schedule your > devroom as you wish (presentations, discussions, brainstorming, > workshops, BOFs, hacking sessions, ...). > > Do allow us to repeat the obvious: FOSDEM is a FOSS community > event, by and for the community, and the content and topics > _must_ reflect that (arguably, that is pretty obvious). It is > also a technical conference, as our view is that the very broad > spectrum of Free and open source projects should work together > rather than fighting religious wars -- at least when at FOSDEM > -- and we would like you to respect that, especially given the > very diverse palette of projects that are present at the event. > > We invite you to send out an open call for talks to relevant > mailinglists, including fosdem(a)lists.fosdem.org. > We will collect all call for talks and announce them on our > website next week. > > We offer each of the devrooms a NAME-devroom(a)fosdem.org mailman > mailinglist, in case you want to have a mailinglist "on neutral > grounds". This can be especially interesting for devrooms that > aggregate several projects. > Contact us at devrooms(a)fosdem.org to take on this offer. > > We will most probably provide you with a tool (website) to send > us the schedule containing all information necessary for the > website and the booklet. More information on that later, as it > is still work-in-progress. (Yeah, we said that last year too but > it might actually work this time ;)) > > The hours listed above are the schedulable hours. We recommend > to plan the first 15min or so with a little welcome talk so you > can prepare the first "real" speaker (network, connect to video > projector, etc...). We can also open the room a bit earlier for > preparations. We expect the rooms to be empty 30 minutes after > the last talk on your schedule, as we need to clean the rooms up > and close them with the security staff. > > For stocking material overnight, we have a large room in the H > building ("Ferrer", next to the Infodesk) that will be locked > from Saturday 18:00 to Sunday 09:00. However, there is no > insurance whatsoever and we take no responsibility for stolen or > damaged goods, even though there is a security team at the > venue, including during the night. > > For us, you are the devroom responsible. This means that we will > communicate everything through you, and you will be the one we > will poke for information ;) > > Also, during the weekend, we want you to do good housekeeping of > the room: > - we will offer trash bags for the garbage, and we would very > much welcome not finding garbage lying around in the room when > you leave (simply draw the attention of the crowd in your > devroom on that point on a regular basis), > - there is a limit on the room capacity that may not be exceeded > (by much) for obvious security reasons. > > Please understand that we are a non for profit association, and > that every single organization team member works on FOSDEM > during their spare time. As such, it would be very nice if we > didn't have to spend several hours cleaning up the devrooms, and > it is just a very small amount of work for the attendees to put > their garbage into the trash bags. We will supply each room with > a sufficient amount of the latter. > > The deadline for sending in the full schedule will be Saturday > 2012-01-21, so we advise you to decide on the content by the > turn of the year or earlier (earlier = more time for > participants to book their arrangements for travel and stay). > We don't do that to put you artificially under pressure but, > instead, in order to have the complete schedule to present to > visitors and on the various mobile applications for the FOSDEM > schedule, as well as to include your devroom schedule into the > booklet. There are 21 sessions in parallel at all times during > the event and, hence, if you would like to draw some crowd of > interested contributors, it does help when it's on the schedule > :) > > Lastly, we wish to clarify that there are no reimbursements of > travel or hotel costs for devroom organizers/speakers on our > behalf. The idea behind the devrooms is that we provide the > infrastructure (room, video projector, wifi internet uplink) for > free to Free and open source projects, and your job is to spread > a public or internal call for papers to your respective > community, collect those proposals, compose a schedule, and > provide us with that information. > > You are of course free to find your own sponsors to fund costs > for participants, but they will not be endorsed as "FOSDEM > sponsors" and hence not listed in the sponsors section on our > website. > > > And, of course, if you have any questions, please do not > hesitate to contact us at devrooms(a)fosdem.org > > For urgent matters, you may also contact me (Pascal Bleser) on > my mobile: +32 486 071035 -- I speak French and German as native > languages and English fluently. Please keep in mind that I live > in the CET timezone though :) > > > Looking forward to your participation, > On behalf of the FOSDEM team, > -- > Pascal Bleser <loki(a)fosdem.org> http://fosdem.org/ > FOSDEM 2012 ::: 4 + 5 February 2012 in Brussels, Belgium > Free and Opensource Software Developers European Meeting

Nov. 11, 2011