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

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

by Igor Stasenko

On 7 December 2010 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> 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. > > Igor why? > > why remove: does not take the same argument than add: and does what it should? > because with collection you can do: collection copy do: [:xx | collection remove: xx ]. or collection removeAll: (collection select: [:each | each isOdd ] ) but not with dictionary. So i don't see much reason fixing #remove: because we never going to fix #do: anyways, which makes all beautiful manipulations with collections useless 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 hope not. > > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by Diogenes Moreira

Well sow sow, Very offen, then choice makers, looking for, "security" (talking about people, policy and technology) . "I'm select java because PWC recommend it for this solution'".."Cover your ass" Puaj..Puaj In the second place the choice makers select the technologies, defending he's budget. Not select the cheaper o better solutios.. Fight for manteing or increse, the IT budget.. "More budget..More power.. Say the CIOs (Common Idiot Officer) . Other fact, (at least in Argentine)the CIO don't have real weight in the organization and denpends of Operation or Financials. I don't know where come from the stupid idea that the IT area can be manage for a non-tech people.. I can guess from Accountants..or Lawyers :). In 3th place, the choice makers looking for fame. nobody was selected as InfomationWeek's CIO of Year for select Smaltalk as Core Technology. (The mainstream software houses are sponsor of this cain of publications). In last place the choice makers select the technologies for it's capabilities and "state of art" that he has in your organization. Actually the average programmers don't know the true OOP. I think, Pharo goes in good way..but the finishline is a far far a way. We must continue teaching in the universities..and why not.. The companies.. For free.... Only for introduce the technollogy in the market We must support projects such Seaside, Reef, Glorp, SqueakDBX or Mars (and it's futures version for linux and windows). This cain of projects are the bridge from the mainstream world to smalltalk.. Rigth now, in the mind of traditonal choice maker, a solution without a relational DB(Oracle or something like that) is only "a beatyfull toy". are year a mean. Traditional pieces of software give "Security". We must make deal's with the traditional software companies.. And don't be scare for sign a contract where the project have webservices and java, php or .net front-end. although the solution is not neededâ¬.(Obviously if you don't will be the architect :) ) We need make the peace with commercial people and the technology publications.. At last and over all, when any one from this group, have the chance, one chance, to have a CIO position, take it, and make the difference. This one, please don't think as traditional CIO, think different. Sorry for the large mail and my english Best. 2010/12/7, Guillermo Polito <guillermopolito(a)gmail.com>: > Do we have marketing people? We need someone selling smalltalk to business > people. :P > > In most cases (at least here in Argentina), the technology is decided by non > technical people (like managers or customers) because they heard something > called java and someone recommended it to them... > > Sad. > > On Mon, Dec 6, 2010 at 10:43 PM, <csrabak(a)bol.com.br> wrote: > >> Em 06/12/2010 18:21, Tudor Girba < tudor.girba(a)gmail.com > escreveu: >> >> > Hi, >> > I believe Smalltalk is perceived in the following way: >> > 1. Smalltalk is cool: 0.01% >> > 2. What is Smalltalk?: 19,99% >> > 3. Smalltalk is dead: 80% >> >> I think your assessment is not that far from reality... :-( >> >> > It is hard to convince the 2nd category to look at something >> > new. Why should they? But, if it's hard to convince someone of >> > something new, you need a miracle to convince someone that something >> > is not dead. But, I think that a miracle like this can be >> > administrated in the form of cool and kicking creatures and then >> > tell them that they kick because of Smalltalk :) >> >> I agree on the feeling, I only think we all miss a very important >> tactical point here: in what realm is Smalltalk superior to other >> technologies? While we cannot answer this without hesitation and >> without half escuses on why this 'superiority' don't show itself, >> we're stuck to feelings and trying to present cherry picked 'examples' >> of the qualities of our pet language/technology. >> >> The issue some cool and kicking creatures could have been done is not >> enough, we need also to be certain we can get newcomers and have them >> quickly up to speed in doing so. _That_ has lead other ('younger') >> languages to their present status. >> >> -- >> Cesar Rabak >> >> > -- Enviado desde mi dispositivo mÃ³vil

Dec. 7, 2010

Re: [Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!

by StÃ©phane Ducasse

On Dec 7, 2010, at 12:41 PM, Lukas Renggli wrote: >> One change that I don't understand, although it probably is unrelated, is in [2]: >> >> LargePositiveInteger removeSelector: #=! >> LargePositiveInteger removeSelector: #bitAnd:! >> LargePositiveInteger removeSelector: #bitOr:! >> LargePositiveInteger removeSelector: #bitShift:! >> LargePositiveInteger removeSelector: #bitXor:! >> LargePositiveInteger removeSelector: #'~='! >> >> Why would one want to remove these primitive calls from large integers? > > AFAIK, Cog needs those. In float? But apparently eliot removed them in for Cog in LargePositiveInteger. Can somebody check that point? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 7, 2010

Re: [Pharo-project] Bad characters in update package names

by StÃ©phane Ducasse

On Dec 7, 2010, at 12:46 PM, Gary Chambers wrote: > As Guillermo pointed out > 'Issue 3191: SparseLargeArray-MarcusDenker.2.mcz' this is the name of the package!!!! Argh jean-baptiste? I will fix it now. Stef > > Amongst others... > Windows will fail to create the local file in package-cache due to the colon in the name... > > Regards, Gary > > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, December 07, 2010 11:33 AM > Subject: Re: [Pharo-project] Bad characters in update package names > > > Gary do you have the name of the package? > And yes we should check that. I know that luc wrote some doc to make sure that package names would not contain stupid characters. > > On Dec 6, 2010, at 5:02 PM, Gary Chambers wrote: > >> Seems didn't get sent... >> >> Regards, Gary >> ----- Original Message ----- >> From: Gary Chambers >> To: Pharo Development >> Sent: Friday, December 03, 2010 4:02 PM >> Subject: Bad characters in update package names >> >> It seems that having $: in the package name for certain updates is causing >> the save to local package cache to error on Windows (unsurprisingly). >> >> Perhaps worth having a sanity check before the package name is accepted >> since it eventually gets to the filesystem. >> >> Regards, Gary > > >

Dec. 7, 2010

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

by StÃ©phane Ducasse

did you create an issue? and where did you publish the code? >>> 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 > > Regardless of what comes of those packages I uploaded, SmallDictionary>>remove: and SmallDictionary>>remove:ifAbsent: returning two different values is clearly a bug. Looking at it again, I was wrong about SmallDictionary>>remove:ifAbsent: returning the key; it does return the removed association. Which means at a minimum, SmallDictionary>>remove: only needs to have a ^ inserted at its beginning to fix the discrepancy. > >> - 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. 7, 2010

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

by StÃ©phane Ducasse

>> >> 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. Igor why? why remove: does not take the same argument than add: and does what it should? >> 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 hope not.

Dec. 7, 2010

Re: [Pharo-project] Bad characters in update package names

by Gary Chambers

As Guillermo pointed out 'Issue 3191: SparseLargeArray-MarcusDenker.2.mcz' Amongst others... Windows will fail to create the local file in package-cache due to the colon in the name... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, December 07, 2010 11:33 AM Subject: Re: [Pharo-project] Bad characters in update package names Gary do you have the name of the package? And yes we should check that. I know that luc wrote some doc to make sure that package names would not contain stupid characters. On Dec 6, 2010, at 5:02 PM, Gary Chambers wrote: > Seems didn't get sent... > > Regards, Gary > ----- Original Message ----- > From: Gary Chambers > To: Pharo Development > Sent: Friday, December 03, 2010 4:02 PM > Subject: Bad characters in update package names > > It seems that having $: in the package name for certain updates is causing > the save to local package cache to error on Windows (unsurprisingly). > > Perhaps worth having a sanity check before the package name is accepted > since it eventually gets to the filesystem. > > Regards, Gary

Dec. 7, 2010

Re: [Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!

by Lukas Renggli

> One change that I don't understand, although it probably is unrelated, is in [2]: > > LargePositiveInteger removeSelector: #=! > LargePositiveInteger removeSelector: #bitAnd:! > LargePositiveInteger removeSelector: #bitOr:! > LargePositiveInteger removeSelector: #bitShift:! > LargePositiveInteger removeSelector: #bitXor:! > LargePositiveInteger removeSelector: #'~='! > > Why would one want to remove these primitive calls from large integers? AFAIK, Cog needs those. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 7, 2010

Re: [Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!

by Adrian Lienhard

The changes between 1.1 and 1.1.1 are the issues in [1]. None seems related... did I miss something? One change that I don't understand, although it probably is unrelated, is in [2]: LargePositiveInteger removeSelector: #=! LargePositiveInteger removeSelector: #bitAnd:! LargePositiveInteger removeSelector: #bitOr:! LargePositiveInteger removeSelector: #bitShift:! LargePositiveInteger removeSelector: #bitXor:! LargePositiveInteger removeSelector: #'~='! Why would one want to remove these primitive calls from large integers? Cheers, Adrian [1] http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D1.1.1&colspe… [2] http://code.google.com/p/pharo/issues/attachmentText?id=2912&aid=-244293168… On Dec 7, 2010, at 09:52 , Mariano Martinez Peck wrote: > ---------- Forwarded message ---------- > From: David T. Lewis <lewis(a)mail.msen.com> > Date: Tue, Dec 7, 2010 at 2:06 AM > Subject: Re: [Vm-dev] Image freeze because handleTimerEvent and Seaside > process gone?! > To: Squeak Virtual Machine Development Discussion < > vm-dev(a)lists.squeakfoundation.org>, adi(a)netstyle.ch > > > > On Mon, Dec 06, 2010 at 12:33:59PM -0800, Andreas Raab wrote: >> >> At a guess, I'd say it's either one of two issues: >> >> 1) Your STOP/CONT handling. This sounds suspicious and it could affect >> the timer handling. I'm assuming that the issue happens after receiving >> the CONT signal, no? If you can, you might want to a) make sure that you >> only get the STOP signal when the VM is in ioRelinquish() and not (for >> example) currently executing the delay process and b) consider to dump >> the call stacks whenever the VM gets the CONT signal to see what the >> status is. >> >> 2) Some set of incomplete process/delay/semaphore changes in Pharo. One >> of the problems with processes and delays is that this part of the >> system reacts very badly to random "cleaning". I.e., changing "foo == >> nil" to "foo isNil" can have dramatic effects (since it introduces a >> suspension point) with just the kind of weird issue you're seeing. > > Actually #2 does seem like a likely culprit. I found a Pharo 1.1 image > and loaded the CommandShell and OSProcess test suites. The CommandShell > tests put a heavy load on process switching, and are rather timing > dependent. On Pharo 1.1 I get intermittent and non-reproducible errors > and test failures, and I can't get a clean run of the test suite. The > errors seem to be different each time. > > On Pharo 1.1.1 and 1.2 I can get clean runs of the CommandShell/OSProcess > tests, so I think there must be some issues in Pharo 1.1. If you are > using PharoCore 1.1 now and have the option of moving to Pharo 1.1.1 > or 1.2, I suspect you may see the problems go away. > > Dave > > >> >> With regards to these processes not being printed, that's a side effect >> of how printAllStacks gathers the processes - it will not print >> suspended processes which explains why the UI process doesn't print and >> most likely handleTimerEvent is suspended in a debugger. >> >> Depending on how important this issue is you can also try to dissect the >> object memory itself. If you call writeImageFile (or is it >> writeImageFileIO?) from gdb it will dump the .image file and you can use >> the simulator to look at it more closely. Most likely you'll be able to >> find the processes and look at their stacks. >> >> Cheers, >> - Andreas >> >> On 12/6/2010 2:55 AM, Adrian Lienhard wrote: >>> >>> Hi all, >>> >>> We've been experiencing an "interesting" problem: the image freezes and >>> does not response to HTTP requests anymore after it has been running for >>> days. >>> >>> Here some basic information about our setup: >>> >>> Squeak VM 4.0.3-2202 compiled with gcc 4.3.2 >>> PharoCore 1.1 >>> OS Debian Lenny amd64 (CPUs are 4 Intel Xeon E5530 2.40GHz) >>> >>> - We have never seen the problem with the Squeak VM 3.9-9 and Squeak 3.9 >>> on the identical machine and with the same application source (modulo > some >>> adaptations to make it run on Pharo). >>> - We run the VM with -mmap 512m -vm-sound-null -vm-display-null, and the >>> UI process is suspended (Project uiProcess suspend) >>> - VM does not hog the CPU and memory usage is normal >>> - The meantime between failure is several weeks and we haven't managed to >>> reproduce the problem >>> - The application mainly serves HTTP requests. When the image does not >>> receive requests for some time we send it a STOP signal, when a request >>> comes in it is sent a CONT signal. >>> - lsof shows >>> TCP *:9093 (LISTEN) >>> TCP server:9093->server:46930 (CLOSE_WAIT) >>> >>> Below is a GDB backtrace and the Smalltalk stacks from an image that was >>> frozen (the VM had been running for almost 100 hours): >>> >>> ============================================================= >>> (gdb) bt >>> #0 0x08072020 in ?? () >>> #1<signal handler called> >>> #2 0xb766f5e0 in malloc () from /lib/libc.so.6 >>> #3<function called from gdb> >>> #4 0xb76c50c8 in select () from /lib/libc.so.6 >>> #5 0x08071063 in aioPoll () >>> #6 0xb778bb8d in ?? () from > /usr/lib/squeak/4.0.3-2202//so.vm-display-null >>> #7 0x000003e8 in ?? () >>> #8 0x997b5a34 in ?? () >>> #9 0xbfe7cb28 in ?? () >>> #10 0x08074575 in ioRelinquishProcessorForMicroseconds () >>> Backtrace stopped: frame did not save the PC >>> >>> (gdb) call printCallStack() >>> -1719969228>idleProcess >>> -1719969320>startUp >>> -1740134028 BlockClosure>newProcess >>> $3 = -1755344892 >>> >>> (gdb) call (int) printAllStacks() >>> Process >>> -1719969228>idleProcess >>> -1719969320>startUp >>> -1740134028 BlockClosure>newProcess >>> >>> Process >>> -1740113860>finalizationProcess >>> -1740113952>restartFinalizationProcess >>> -1740113532 BlockClosure>newProcess >>> >>> Process >>> -1740134424 SmalltalkImage>lowSpaceWatcher >>> -1740134516 SmalltalkImage>installLowSpaceWatcher >>> -1740134300 BlockClosure>newProcess >>> >>> Process >>> -1719451488 Delay>wait >>> -1719451580 BlockClosure>ifCurtailed: >>> -1719451704 Delay>wait >>> -1719451796 InputEventPollingFetcher>waitForInput >>> -1740126940 InputEventFetcher>eventLoop >>> -1740127032 InputEventFetcher>installEventLoop >>> -1740126816 BlockClosure>newProcess >>> >>> Process >>> -1719557780 UnixOSProcessAccessor>grimReaperProcess >>> -1740113624 BlockClosure>repeat >>> -1740113716 UnixOSProcessAccessor>grimReaperProcess >>> -1740117340 BlockClosure>newProcess >>> >>> [omitted many newlines between output above] >>> ============================================================= >>> >>> What is striking from the above process listing is that two processes are >>> missing: the handleTimerEvent process and the Seaside process (that is, >>> the TCP listener loop). How comes these processes vanished? >>> >>> This may be related to Pharo or to the Squeak VM. >>> >>> Has anybody else seen this problem? Any idea how to debug/fix this issue >>> is very much appreciated! >>> >>> Cheers, >>> Adrian >>> >>> >>> CCed to pharo-dev since this may be related to Pharo; please respond on >>> the squeak-vm list >>> >>> >>>

Dec. 7, 2010

Re: [Pharo-project] Bad characters in update package names

by StÃ©phane Ducasse

Gary do you have the name of the package? And yes we should check that. I know that luc wrote some doc to make sure that package names would not contain stupid characters. On Dec 6, 2010, at 5:02 PM, Gary Chambers wrote: > Seems didn't get sent... > > Regards, Gary > ----- Original Message ----- > From: Gary Chambers > To: Pharo Development > Sent: Friday, December 03, 2010 4:02 PM > Subject: Bad characters in update package names > > It seems that having $: in the package name for certain updates is causing > the save to local package cache to error on Windows (unsurprisingly). > > Perhaps worth having a sanity check before the package name is accepted > since it eventually gets to the filesystem. > > Regards, Gary

Dec. 7, 2010