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

[Pharo-project] [ANN] 1.2 Dev Packages are loading :)
by Guillermo Polito Dec. 7, 2010

Dec. 7, 2010

Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces as a temporary solution. To load current configuration: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. (ConfigurationOfPharo project version: '1.2-beta2') load. Can Hudson help us in building Dev images? Cheers PS: I've noticed a little bug in OB, I attach a screenshot. On Tue, Dec 7, 2010 at 3:36 AM, Alain Plantec <alain.plantec(a)free.fr> wrote: > Le 07/12/2010 07:04, Guillermo Polito a Ã©crit : > > Well I've gone very far by now :). >> >> I created a configuration that at least loads :P. >> >> There are two problems so far: >> >> 1) ECompletion + TextEditor. ECompletion sends #model to TextEditor and >> It does not understands it. It is easily fixed adding the accessor. >> 2) Opening an omnibrowser throws a MessageNotUnderstood: >> TextMorphForShoutEditor>>findText. Which I will have a look tomorrow. >> > > See issue 3288, there is a .cs for that I guess. > 3288 <http://code.google.com/p/pharo/issues/detail?id=3288> > > Cheers > Alain > > >> The version of ConfigurationOfPharo is 1.2-beta2 >> >> I've to sleep now :). >> Tomorrow I'll open an issue for 1) if everyone agrees. With whom should I >> talk to get 2) fixed? Lukas, Alain? >> >> Cheers! >> > > >

2 3

Re: [Pharo-project] Issue 1809 in pharo: Nice to have : auto-format on save
by pharo＠googlecode.com Dec. 7, 2010

Dec. 7, 2010

Updates: Status: Fixed Comment #5 on issue 1809 by renggli: Nice to have : auto-format on save http://code.google.com/p/pharo/issues/detail?id=1809 This was implemented at ESUG 2010: Refactoring Engine -> Auto Format on Accept Note: There is also Refactoring Engine -> Auto Format on Display

1 1

Re: [Pharo-project] IRC monthly meeting + project description
by Marcus Denker Dec. 7, 2010

Dec. 7, 2010

On Dec 7, 2010, at 2:43 PM, StÃ©phane Ducasse wrote: > Ok so at 20h00 we get our first IRC meeting. See U there. > I have tickets for a concert tonight... lille orchestra playing la Symphonie fantastique So I can not join. (or maybe afterwards) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2

[Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!
by Mariano Martinez Peck Dec. 7, 2010

Dec. 7, 2010

---------- 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 > > > > > >

6 5

[Pharo-project] Bad characters in update package names
by Gary Chambers Dec. 7, 2010

Dec. 7, 2010

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

3 8

Re: [Pharo-project] IRC monthly meeting + project description
by Marcus Denker Dec. 7, 2010

Dec. 7, 2010

On Dec 7, 2010, at 2:43 PM, StÃ©phane Ducasse wrote: > Ok so at 20h00 we get our first IRC meeting. See U there. > I have tickets for a concert tonight... lille orchestra playing la Symphonie fantastique So I can not join. (or maybe afterwards) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Native Windows in Pharo
by Geert Claes Dec. 7, 2010

Dec. 7, 2010

Hi Andres, Ideas and suggestions are very welcome in the Pharo community and they are mainly discussed here rather than in a UserVoice or GetSatisfaction environment. Idea voting is an excellent way to engage customers and users to improve products. The only thing Stef and Doru are saying (at least thats how I read it) is that Pharo doesn't necessarily have a shortage of ideas or lack of direction, but simply not enough people to do all the work. So yes, ideas and feature requests are great and please do continue to post them here as there are many enthusiastic skilled Smalltalkers that can help, advice and guide you. When you find something is missing or can be improved, you are more encouraged to contribute towards the solution rather than just vote. Getting back to your original post though, congrats getting your in-house project! How about a rich Seaside, AIDAWeb or Iliad browser based app? Cheers, Geert Andres Fortier-2 wrote: > > Stef, Doru: > > first of all I was *asking if* such a model exists, not demanding one. > Having just entered the Pharo world I wanted to know how you guys handle > the feature requests. I see now. > > On the other hand if you really want to discuss the question of "who has > the rights for asking for X" in the open source model I'm open, but just > to be sure I will first ask: Is it ok to open such a thread? Or should I > first contribute to Pharo before asking? > > AndrÃ©s > -- View this message in context: http://forum.world.st/Native-Windows-in-Pharo-tp3071794p3076336.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 3

Dec. 7, 2010

Hi guys I imagine that a lot of you are missing a vision or the path of actions in Pharo. So I want to fix that because it will give you a chance to participate and get the vision. I'm starting to produce some slides that describe the challenges we should address I suggest that we start also a monthly IRC chat the first/second tuesday of the month. I propose tuesday 7 at 18h00 or 20h00 Paris time so that other people can join. Le me know what you think about it. Stef

7 8

[Pharo-project] Pharo 1.1.1 (CogVM) crashes when saving Monticello packages to any repository due to possible bug in primitive UUID generation
by jaayer Dec. 7, 2010

Dec. 7, 2010

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. 0xffdda054 M UUID>initialize -1222112984: a(n) UUID 0xffdda06c M UUID class(Behavior)>new: -1246280952: a(n) UUID class 0xffdda090 I UUID class>new -1246280952: a(n) UUID class 0xffdda0b8 I MCWorkingAncestry>infoWithName:message: -1237212252: a(n) MCWorkingAncestry 0xffdda0e8 I MCWorkingCopy>newVersionWithName:message: -1237214288: a(n) MCWorkingCopy 0xffdda114 I MCWorkingCopy>newVersion -1237214288: a(n) MCWorkingCopy 0xffdda13c I MCWorkingCopyBrowser>saveVersion -1224547984: a(n) MCWorkingCopyBrowser 0xffdda15c I PluggableButtonMorphPlus(PluggableButtonMorph)>performAction -1224524124: a(n) PluggableButtonMorphPlus 0xffdda17c I PluggableButtonMorphPlus>performAction -1224524124: a(n) PluggableButtonMorphPlus 0xffdda198 M [] in PluggableButtonMorphPlus(PluggableButtonMorph)>mouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda1bc M Array(SequenceableCollection)>do: -1224322708: a(n) Array 0xffdda1e4 I PluggableButtonMorphPlus(PluggableButtonMorph)>mouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda208 I PluggableButtonMorphPlus>mouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda224 M PluggableButtonMorphPlus(Morph)>handleMouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda240 M MouseButtonEvent>sentTo: -1224322748: a(n) MouseButtonEvent 0xffdda25c M PluggableButtonMorphPlus(Morph)>handleEvent: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda278 M PluggableButtonMorphPlus(Morph)>handleFocusEvent: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda2a0 M [] in HandMorph>sendFocusEvent:to:clear: -1245777988: a(n) HandMorph 0xffdda2bc M [] in PasteUpMorph>becomeActiveDuring: -1245489536: a(n) PasteUpMorph 0xffdda2d8 M BlockClosure>on:do: -1224322800: a(n) BlockClosure 0xffdda304 M PasteUpMorph>becomeActiveDuring: -1245489536: a(n) PasteUpMorph 0xffdda328 M HandMorph>sendFocusEvent:to:clear: -1245777988: a(n) HandMorph 0xffdda350 M HandMorph>sendEvent:focus:clear: -1245777988: a(n) HandMorph 0xffdda374 M HandMorph>sendMouseEvent: -1245777988: a(n) HandMorph 0xffdda398 M HandMorph>handleEvent: -1245777988: a(n) HandMorph 0xffdda3c4 M HandMorph>processEvents -1245777988: a(n) HandMorph 0xffdda3dc M [] in WorldState>doOneCycleNowFor: -1244859188: a(n) WorldState 0xffdda400 M Array(SequenceableCollection)>do: -1247208360: a(n) Array 0xffdda41c M WorldState>handsDo: -1244859188: a(n) WorldState 0xffdda438 M WorldState>doOneCycleNowFor: -1244859188: a(n) WorldState 0xffdda454 M WorldState>doOneCycleFor: -1244859188: a(n) WorldState 0xffdda470 M PasteUpMorph>doOneCycle -1245489536: a(n) PasteUpMorph 0xffdda490 I [] in Project class>? -1244779680: a(n) Project class -1245658620 s [] in BlockClosure>? Most recent primitives basicNew basicNew @ @ basicNew @ @ @ basicNew basicNew truncated fractionPart fractionPart truncated fractionPart truncated fractionPart truncated basicNew truncated basicNew truncated fractionPart fractionPart truncated fractionPart truncated fractionPart truncated basicNew truncated perform:with: perform:with: basicNew truncated @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ basicNew @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ copyBits @ @ basicNew at:put: basicNew new: at:put: species basicNew new: species basicNew new: species basicNew new: at:put: at:put: species basicNew new: @ @ basicNew at:put: @ @ basicNew at:put: species species species species species species replaceFrom:to:with:startingAt: at:put: new: at:put: at:put: @ @ basicNew shallowCopy shallowCopy basicNew new: at:put: shallowCopy new: replaceFrom:to:with:startingAt: at:put: shallowCopy basicNew basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew at:put: @ @ basicNew shallowCopy shallowCopy basicNew new: at:put: shallowCopy new: replaceFrom:to:with:startingAt: at:put: shallowCopy basicNew basicNew @ @ basicNew at:put: @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ copyBits @ @ basicNew at:put: basicNew new: species basicNew new: species basicNew new: at:put: at:put: at:put: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primitiveDeferUpdates: forceDisplayUpdate findNextUnwindContextUpTo: terminateTo: basicNew: primMakeUUID Aborted

5 5

Re: [Pharo-project] [ticket #104592] j'ai l'impression que la mailing-list de pharo ne marche plus
by DUCASSE Stephane via RT Dec. 7, 2010

Dec. 7, 2010

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 >> >> > > >

1 0