- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Pharo 1.1.1 (CogVM) crashes when saving Monticello packages to any repository due to possible bug in primitive UUID generation

by StÃ©phane Ducasse

yes it would be good. Stef On Dec 5, 2010, at 10:37 PM, Mariano Martinez Peck wrote: > marcus, maybe we can fix this for the one clicks? > > cheers > > mariano > > On Sun, Dec 5, 2010 at 10:12 PM, jaayer <jaayer(a)zoho.com> wrote: > > > > > ---- On Sun, 05 Dec 2010 12:55:17 -0800 Igor Stasenko wrote ---- > > >On 5 December 2010 20:53, jaayer wrote: > >> > >> > >> I have found that I cannot save any package to any repository (local or Squeaksource) using Pharo 1.1.1 with the CogVM on 64-bit Ubuntu 10.10. After being prompted to describe the changes to the package and then accepting, the entire image just crashes with the stack dump below. I do have the proper IA32-libs installed (to run 32-bit applications on a 64-bit Linux), and everything else seems to work fine, including loading of Monticello packages. > >> > >> This code: "UUID new primMakeUUID" can produce the crash. Changing UUID>>primMakeUUID to use the non-primitive implementation: > >> UUIDGenerator default generateBytes: self forVersion: 4. > >> stops the crashing. > >> > > > >UUID bug is well known for a long time. > >It is plaguing us for 2 years i think. > > I see, my mistake. I assumed it was new because this is the first time I have ever encountered it on Linux after two years of using Pharo, and there were no recent posts here discussing it (though searching just now, I found a thread concerning Cog and UUID crashes from last October) or related issues in the tracker that I could find. But I feel compelled to stress that the current Pharo 1.1.1 OneClick distribution is shipping with this bug in it, and the previous 1.1 distribution did not. Perhaps this quarrelsome plug-in should be disabled by default, if only on Linux. I would hate for a budding Pharo user to encounter this while going through the exercises in Pharo By Example. > > >-- > >Best regards, > >Igor Stasenko AKA sig. > > > > > > >

Dec. 7, 2010

Re: [Pharo-project] [ticket #104592] j'ai l'impression que la mailing-list de pharo ne marche plus

by DUCASSE Stephane via RT

apparemment c'est le passae a zimbra qui m'a eu. Donc j'ai fixe mes settings mails. Desole Stef On Dec 6, 2010, at 7:39 PM, DEXHEIMER Benjamin via RT wrote: > Bonjour, > > S'agit-il bien de la liste "pharo-project" ? > Si oui, le dernier message est datÃ© du "Last message date: Mon Dec 6 > 19:11:38 CET 2010". > En parcourant l'archive par thread, il y a effectivement des messages du > 6 dÃ©cembre, fin d'aprÃ¨s-midi. > Pourriez-vous peut-Ãªtre prÃ©ciser les Ã©lÃ©ments qui vous laissent Ã penser > Ã une panne de la liste ? > > Cordialement, > > -- > BD / ET-INRIA_GForge > > > > On Fri Dec 03 22:12:07 2010, sducasse wrote: >> pouvez-vous verifier? >> merci >> >> > > >

Dec. 7, 2010