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

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

Re: [Pharo-project] Problem updating Pharo Core

by Gary Chambers

Does the build server run Windows? (c.f. $: in package name). Regards, Gary ----- Original Message ----- From: Marcus Denker To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, December 06, 2010 9:11 PM Subject: Re: [Pharo-project] Problem updating Pharo Core On Dec 6, 2010, at 7:59 PM, Guillermo Polito wrote: I have the last prebuild pharo core (12261), and clicking on update stops in version 12266 with a DNU: nil does not understand binary It has something to do with the monticello a version with this info: 'Issue 3191: SparseLargeArray-MarcusDenker.2.mcz' Did someone had this same issue? the build server seems to have no problem: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/ -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 7, 2010

Re: [Pharo-project] about Z39.50

by StÃ©phane Ducasse

tx On Dec 5, 2010, at 6:21 PM, HernÃ¡n Morales Durand wrote: > Hi Stef > > I've updated the links and tested under Pharo and Seaside One Click. > Cheers, > > > 2010/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi hernan >> >> I cannot find the install instructions for >> A binding of the ZOOM Yaz client for Squeak and Pharo. >> The link is dead on squeaksource. >> >> Should I get something special to query a Z39.50 server? >> >> TX >> Stef >> >> > > > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. >

Dec. 7, 2010

Re: [Pharo-project] Pharocasts: access SQLite databases through ODBC

by StÃ©phane Ducasse

Excellent! On Dec 5, 2010, at 10:25 PM, laurent laffont wrote: > See how to setup and access an SQLite database through ODBC on Windows. > > Recorded by Torsten Bergmann. > > Enjoy: http://www.pharocasts.com/2010/12/access-database-through-odbc.html > > > > Laurent Laffont > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/

Dec. 7, 2010

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

by Mariano Martinez Peck

---------- 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] Category Renaming under Monticello

by Noury Bouraqadi

Hi, A while ago (2-3 years) I submitted the a change to MC and MC Browser to support package renaming and also changing the initials of all classes in the package. It was rejected because it is possible to have a cleaner alternative implementation that makes use of RB. Unfortunately, I didn't manage to do the change. Attached my code. A right click on a package name is supposed to Note however that I didn't test it with recent Pharo images. Noury On 7 dÃ©c. 2010, at 00:05, Sven Van Caekenberghe wrote: > 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. 7, 2010

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

by Dale Henrichs

Okay ... I've got another little rant... Smalltalk improves developer productivity ... pure and simple ... the reason that developing in Smalltalk is fun is that there is very little that gets in between the developer and the solution of a problem ... the debugger, inspector and all of the tools mean that a developer can focus on the problem at hand ... the dynamic nature of Smalltalk means that I can add instance variables and change interfaces without having to fight the compiler or the tools ... or lose track of what I am doing .... With that said (here comes the rant:) ... the _enterprise_ is not necessarily interested in developer productivity...productive developers is way down the list for the enterprise ... just look at the waste (not just in software) in a typical corporation ... (end of rant) ... Smaller companies (not at the enterprise level) _are_ interested in developer productivity, so that should be the sweet spot for Smalltalk and there is work to be done to make Smalltalk more attractive to those Smaller companies and it seems that Pharo is headed in the right direction to become more attractive ... Note that many development groups within the enterprise operate like smaller companies, it's just that a CTO of a Fortune 500 company isn't going to wholesale switch his company from using Java to using Smalltalk (at least not this year:)... Oh and GemStone also has enterprise customers who don't necessarily advertise their Smalltalk success stories. Dale On Dec 6, 2010, at 11:00 PM, laurent laffont wrote: 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? Fun :) Laurent 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

Dec. 7, 2010

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

by laurent laffont

> > > 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? > > Fun :) Laurent > > 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 > >

Dec. 7, 2010

Re: [Pharo-project] Creating a Dev Image

by Alain Plantec

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!

Dec. 7, 2010