December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Comments or no integration: a simple choice for you

by csrabak＠bol.com.br

Otherwise we can find out how small the dev image can really be. . . ;-) Em 06/12/2010 16:46, Sean P. DeNigris < sean(a)clipperadams.com > escreveu: I love this idea! Mariano Martinez Peck wrote: > > The good idae is to push and promote people to put class comments, but not > to remove not commented classes from Dev, bacause otherise, you will need > to > remove 80% of the classes. > It seemed to me this plan is being suggested precisely because "push and promote" has not produced results. In face, I would say this grand challenge is a pretty good "push" ;-) Plus, it's more fun than "trying to put more comments before the next release". Fortune favors the bold! Sean -- View this message in context: http://forum.world.st/Comments-or-no-integration-a-simple-choice-for-you-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by Igor Stasenko

On 7 December 2010 00:18, jaayer <jaayer(a)zoho.com> wrote: > > > > > ---- On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko Â wrote ---- > >>On 6 December 2010 23:52, jaayer Â wrote: >>> >>> >>> >>> >>> ---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer Â wrote ---- >>> >>>>Is anyone else bother[ed] by this inconsistency? >>> >>> Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). >>> >>> >> >>Hello, jaayer. >> >>The point about Dictionary inconsistency was raised multiple times before. >>I was among ones of those who did that couple of years ago. >>What can i say? >>While it is much better to have consistency, >>in fact it doesn't really changes much. I don't think that #remove: in >>a form you proposed will be any userful. >>I would really keep it simply #shouldNotImplement , because it is >>unclear what is a least surprising behavior of this method for >>Dictionary. >>One might argue, that its more userful to make it same as #removeKey:, >>other one could point that its should be symmetrical to #add: , > > #add: is not part of the ANSI <abstractDictionary> protocol. It is, however, part of the ANSI <extensibleCollection> protocol: > add: > addAll: > remove: > remove:ifAbsent: > removeAll: > > One could make the argument that if Dictionary elects to implement part of it, it might as well implement the rest too. > >>but hey, then #do: should be also symmetrical to #add: , isnt? And so >>it should iterate over associations , not just values. So, it is a can >>of worms, once you open it , you can never finish the endless >>discussions :) >>It is just works in a way how we like (defined). It is like an >>imaginary numbers in math where sqrt(-1) == i and basta :) > > Right... I wasn't planning on going there, but are we basically stuck with #do:, #select: #collect:, #includes: and other such messages operating on the Dictionary's values rather than its associations, forever? i think that most sane developers trying to avoid using inconsistent methods with dictionaries , which inherited from Collection protocol. So, instead of #do:, they using #valuesDo: , dict values select: instead of dict select: and so on. Because otherwise, what is the point of introducting #valuesDo:, which completely duplicating #do: behavior? I see nothing, except an attempt to introduce an explicit and more appropriate protocol for Dictionary. And then ban Collection methods, with questionable behavior (depending on who is questioning ;) ). > >>-- >>Best regards, >>Igor Stasenko AKA sig. >> >> > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 6, 2010

Re: [Pharo-project] Teleplace is hiring...

by Eliot Miranda

On Mon, Dec 6, 2010 at 2:51 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > Are you eager to work on cutting-edge business communications technology? > Are you passionate about UI design? Do you have significant experience > implementing innovative user interfaces in Smalltalk? Do you and your peers > consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring > and looking for someone just like you. Please send resumes to Stephen > Ceplenski <steve(a)teleplace.com>, Andreas Raab <andreas.raab(a)teleplace.com> > or myself, Eliot Miranda <eliot(a)teleplace.com>. > > best > Eliot > P.S. A lot of you are asking abut location and whether telecommuting would be possible. Essentially we're flexible. For an exceptional candidate we would try to work with them but ideally the person would be either in or able to relocate to the San Francisco Bay Area. Finding your feet in Teleplace's technology will be a challenge; this is not a straight-forward Smalltalk application, using tea-time, tweak, lots of server-side work and so on. So to find one's feet being in the office will really help. Best that you send in your resumes if you're interested, stating your residency requirements, and let us see where things go from there. best Eliot

Dec. 6, 2010

Re: [Pharo-project] [squeak-dev] Teleplace is hiring...

by GermÃ¡n Arduino

Indeed, very very good news to Smalltalk community. 2010/12/6 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi All, > Are you eager to work on cutting-edge business communications technology? > Â Are you passionate about UI design? Â Do you have significant experience > implementing innovative user interfaces in Smalltalk? Â Do you and your peers > consider yourself a strong Smalltalk programmer? Â If so, Teleplace is hiring > and looking for someone just like you. Â Please send resumes to Stephen > Ceplenski <steve(a)teleplace.com>,Â Andreas Raab <andreas.raab(a)teleplace.com> > or myself,Â Eliot Miranda <eliot(a)teleplace.com>. > best > Eliot > > >

Dec. 6, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by jaayer

---- On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko wrote ---- >On 6 December 2010 23:52, jaayer wrote: >> >> >> >> >> ---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer Â wrote ---- >> >>>Is anyone else bother[ed] by this inconsistency? >> >> Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). >> >> > >Hello, jaayer. > >The point about Dictionary inconsistency was raised multiple times before. >I was among ones of those who did that couple of years ago. >What can i say? >While it is much better to have consistency, >in fact it doesn't really changes much. I don't think that #remove: in >a form you proposed will be any userful. >I would really keep it simply #shouldNotImplement , because it is >unclear what is a least surprising behavior of this method for >Dictionary. >One might argue, that its more userful to make it same as #removeKey:, >other one could point that its should be symmetrical to #add: , #add: is not part of the ANSI <abstractDictionary> protocol. It is, however, part of the ANSI <extensibleCollection> protocol: add: addAll: remove: remove:ifAbsent: removeAll: One could make the argument that if Dictionary elects to implement part of it, it might as well implement the rest too. >but hey, then #do: should be also symmetrical to #add: , isnt? And so >it should iterate over associations , not just values. So, it is a can >of worms, once you open it , you can never finish the endless >discussions :) >It is just works in a way how we like (defined). It is like an >imaginary numbers in math where sqrt(-1) == i and basta :) Right... I wasn't planning on going there, but are we basically stuck with #do:, #select: #collect:, #includes: and other such messages operating on the Dictionary's values rather than its associations, forever? >-- >Best regards, >Igor Stasenko AKA sig. > >

Dec. 6, 2010

Re: [Pharo-project] Teleplace is hiring...

by Peter Hugosson-Miller

Great news to hear that there *are* Smalltalk jobs out there after all! :-) But, still none in Sweden (yet) :-( Good luck finding the right person (or persons)! -- Cheers, Peter On Mon, Dec 6, 2010 at 11:51 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > Are you eager to work on cutting-edge business communications technology? > Are you passionate about UI design? Do you have significant experience > implementing innovative user interfaces in Smalltalk? Do you and your peers > consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring > and looking for someone just like you. Please send resumes to Stephen > Ceplenski <steve(a)teleplace.com>, Andreas Raab <andreas.raab(a)teleplace.com> > or myself, Eliot Miranda <eliot(a)teleplace.com>. > > best > Eliot >

Dec. 6, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by Igor Stasenko

On 6 December 2010 23:52, jaayer <jaayer(a)zoho.com> wrote: > > > > > ---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer Â wrote ---- > >>Is anyone else bother[ed] by this inconsistency? > > Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). > > Hello, jaayer. The point about Dictionary inconsistency was raised multiple times before. I was among ones of those who did that couple of years ago. What can i say? While it is much better to have consistency, in fact it doesn't really changes much. I don't think that #remove: in a form you proposed will be any userful. I would really keep it simply #shouldNotImplement , because it is unclear what is a least surprising behavior of this method for Dictionary. One might argue, that its more userful to make it same as #removeKey:, other one could point that its should be symmetrical to #add: , but hey, then #do: should be also symmetrical to #add: , isnt? And so it should iterate over associations , not just values. So, it is a can of worms, once you open it , you can never finish the endless discussions :) It is just works in a way how we like (defined). It is like an imaginary numbers in math where sqrt(-1) == i and basta :) -- Best regards, Igor Stasenko AKA sig.

Dec. 6, 2010

Re: [Pharo-project] Category Renaming under Monticello

by Sven Van Caekenberghe

Hendrik, Thanks for all the help. It seems that changing the category programmatically like this works: ((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server') collect: [ :className | Smalltalk globals at: className ]) do: [ :each | each category: 'Zinc-HTTP-Client-Server' ] Now MC did pick up the changes. Sven On 06 Dec 2010, at 16:07, Henrik Johansen wrote: > > On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote: > >> >> On 06 Dec 2010, at 15:42, Henrik Johansen wrote: >> >>> If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. >> >> OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ? >> >> And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ? >> >> Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ? >> >> Anyway, thanks for the reply. >> >> Sven > > IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty. > So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically. > New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either. > > If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename) > > TLDR; > The packages will contain the correct code, if you publish them. > Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition. > > Cheers, > Henry

Dec. 6, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by jaayer

---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote ---- >Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait).

Dec. 6, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by GermÃ¡n Arduino

Sorry if I'm late on this thread, only wanted to say that lot of times in similar discussions I said that "fortunately" Smalltalk is not very popular (In terms that not tons of people and companies are using it). Each one can make its own interpretation :) Just my 0,02. 2010/12/6 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Mon, Dec 6, 2010 at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 6 December 2010 23:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > Hi James, >> > Â Â Â a good list of enterprise projects is >> > >> > hereÂ http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes. >> > Â The high-lights are JP Morgan, and Texas Instruments/Adventa. Â But also >> > try >> > and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's >> > schduling >> > application (computes schedules for the entire German railway system). >> > If you dig you'll find lots of enterprise applications written in >> > Smalltalk. >> > Â When I started working for ParcPlace Systems companies like JPMorgan >> > didn't >> > allow us to name then since using Smalltalk was such an important >> > competitive advantage. Â That shot a lot of feet, indiscriminately >> > amongst >> > both corporate user and vendo aliker. >> > >> That's kind of fun. >> It reminds me the fisherman, who i met once on the lake, >> and when i said that i came here just for one day as a guest of my >> really far relatives, then he smiled >> and started saying everything about fishing, and saying that at his >> place, a fish catching goes like on conveyor, >> but for all people who passed by, he was making a bored face and >> saying that , ohhh.. no fish damn it.. no fish.. >> bad place, reaallyy bad one :) > > it's great for the fisherman, but really bad for the bait shop... > :) :( :/ > best > Eliot > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > >

Dec. 6, 2010