- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo integration in enterprise feedback
by laurent laffont Dec. 8, 2010

Dec. 8, 2010

Hi, I'm looking for feedback on Pharo integration in enterprise. Especially how you have managed to put Pharo in your enterprise. For example, I'm involved in web application development in other languages. For functional testing I'm able to script Selenium using Pharo thanks to WebTester. So Pharo has made a small step at my work. I'm looking for such stories. Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

11 25

[Pharo-project] Smalltalk in small steps ?
by James Ladd Dec. 7, 2010

Dec. 7, 2010

Hi All, As some of you may know I am writing a Smalltalk for the Java Virtual Machine and it is coming along well. http://redline.st with source on http://github.com Recently I came across a series of blog posts by Peter Michaux on Scheme from scratch and I wondered: Would it be worth while for the Smalltalk community, and language enthusiasts if I were to do the same with Redline Smalltalk, that is, make each features implementation part of a blog post and a 'work along' ? Would you like to see this and or work along with Redline ? Rgs, James.

6 5

[Pharo-project] ProcessWrapper
by Facundo Vozzi Dec. 7, 2010

Dec. 7, 2010

Hi all, anybody is using ProcessWrapper in Pharo 1.1.1 ? I'm using windows and It works fine on Squeak 4.1.1 but it doesn't on my Pharo 1.1.1 which is my development environment. Thanks in advance, Facu

3 5

[Pharo-project] IRC meeting notes
by Adrian Lienhard Dec. 7, 2010

Dec. 7, 2010

This evening the announced IRC meeting took place. I've published the notes as a blog post on our website: http://pharo-project.org/news?article=irc-meeting-notes Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

2 1

[Pharo-project] 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
by Dale Henrichs Dec. 7, 2010

Dec. 7, 2010

I was thinking about a number of things in the shower this morning and then it occurred to me that it would be interesting to create a shell environment INSIDE a Smalltalk vm. It wouldn't be a complete environment, but it would include a small set of standard unix utilities: - awk - sed - grep the "directory structure" would be the package structure in the image (or maybe multiple views on the image contents) with the basic idea that you 'cd' into a class where there is a 'file' that contains the class attributes. you then 'cd instance/all' and you are in a "directory" of methods where you can 'vi at:put:' and have a vi-like editor come up on the source of the at:put: method of course awk, grep, and sed work on all of these 'source files'... there would be 'executable files' that are simply workspaces ... I know that folks have externalized files, but I don't know if anyone has internalized the shell environment ... The reason for internalizing the shell is that it becomes easy to transition to the debugger and other traditional browsers/windows. The big reason for internalizing the shell is to provide a unix-like interface for Smalltalk that might make transition to the Smalltalk tools easier for folks new to Smalltalk. The secondary reason (and probably just as important) for internalizing the shell, is that the hard-core Smalltalk developers might actually find some utility in using the "smalltalk shell" in the normal course of development and if hard-core developers use it, it will be maintained and might lead to other interesting things... The idea is that the entire "smalltalk shell" would be implemented in Smalltalk so you could bring up browsers with a command ... I've been thinking wistfully back to the days when I lived inside of Emacs in the days before every terminal had a mouse ... back then I put my hands on the keyboard at the start of the day and they stayed there the entire day all window navigation was done via the keyboard ... I lost all of that once I started doing development in Smalltalk... Anyway that about covers todays "ideas from the shower"... Dale

6 11

[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